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TRAITE D^OOPERATIOlSl EN MATIER^^ BREVETS 



Expediteur : le BUREAU INTERNATIONAL 



PCT 

NOTIFICATION RELATIVE 
A LA PRESENTATION OU A LA TRANSMISSION 
DU DOCUMENT DE PRIORITE 

(instruction administrative 41 1 du PCT) 


Destinataire: 

CORLU, Bernard 

! R..II Q A 

PC 62A24 

68,^ route de Versailles 

Boite postale 45 

F-78434 Louveciennes Cedex 

FRANCE 


Date d'expedition (jour/mois/annee) 

26 juin 2001 (26.06.01) 




Reference du dossier du deposant ou du mandataire 
PCT 3884/BC 


NOTIFICATION IMPORTANTE 


Demande internationale no 
PCT/FR01/01506 


Date du depot international (jour/mois/annee) 

17 mai 2001 (17.05.01) 


Date de publication internationale (jour/mois/annee) 
Pas encore publiee 


Date de priorite (jour/mois/annee) 

17 mai 2000(17.05.00) 


Deposant 

BULL CP8 etc 



1. La date de reception (sauf lorsque les lettres "NR" figurent dans la colonne de droite) par le Bureau international du ou des 
documents de priorite correspondant a la ou aux demandes enumerees ci-apres est notifiee au deposant Sauf indication 
contraire consistent en un asterisque figurant a cote d'une date de reception, ou les lettres "NR", dans la colonne de droite, . 
le document de priority en question a ete presente ou transmis au Bureau international d'une maniere conforme a la 

regie 17.1. a) ou b). 

2. Ce formulaire met a jour et remplace toute notification relative a la presentation ou a la transmission du document de priorite 
qui a ete envoyee precedemment. 

3. Un asterisque(*) figurant a cote d'une date de reception dans la colonne de droite signale un document de priorite presente 
ou transmis au Bureau international mais de maniere non conforme a la regie 17.1. a) ou b). Dans ce cas, I'attention du 
deposant est appelee sur la regie 17.1.c) qui stipule qu'aucun office designe ne peut decider de ne pas tenir compte de la 
revendication de priorite avant d'avoir donne au deposant la possibility de remettre le document de priorite dans un delai 
raisonnable en I'espece. 

4. Les lettres "NR" figurant dans la colonne de droite signalent un document de priorite que le Bureau international n'a pas 
regu ou que le deposant n'a pas demande a I'office recepteur de preparer et de transmettre au Bureau international, 
conformement a la regie 17.1. a) ou b), respectivement. Dans ce cas, i'attention du deposant est appelee sur la regie 17.1. c) 
qui stipule qu'aucun office designe ne peut decider de ne pas tenir compte de. la revendication de priorite avant d'avoir donne 
au deposant la possibility de remettre le document de priorite dans un delai raisonnable en I'espece. 

Date de priorite Demande de priorite n° Pavs. office regional ou Date de reception du 

office recepteur selon le PCT document de priorite 

17 mai 2000 (17.05.00) 00/06882 FR 19 juin 2001 (19.06.01) 



Bureau international de I'OMPI 


Fonctionnaire autorise: 


34, chemin des Colombettes 


P. Blanchet (Fax 338.87.40) 


1211 Geneve 20, Suisse 


no detelecopieur (41-22) 740.14.35 


no de telephone (41-22) 338.83.38 


Formulaire PCT/IB/304 Quillet 1998) 


004110315 
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■ IWtTlTOT 

NATIONAL DC 
LA FMOFSItTt 

iNousraitLct 



BREVE^D'lNVENTION 
CERTIFI^ D UTILITE 

REQUETE EN DEUVRANCE 2/2 



REMISE OES PIECES 
OATE 



Reserve a I'INPI 



UEU 



1 7 MAI 2000 
75 INPI PARIS F 

N° DENREGISTREMENT 



Vos references pour ce dossier : 

f/acuttatij) 


FR 3884/BC- 


□ MANDATAIRE 




Nom 


CORLU 


Prenom 


Bernard 


Cabinet ou Societe 


BULL S.A. 


N °de pouvoir permanent et/ou 
de lien contractuel 


PG 4280 


Adresse 


Rue 


68, route de Versailles / PC 58D20 


Code postal et ville 


78434 LOUVECIENNES CEDEX 


N° de telephone (fdad/a/if) 


01.39.66.61.76 I 


N° de telecopie (facullalifi 


01.39.66.61.73 


Adresse electronique t facultatij) 


BERNARD.CORLU@BULL.NET j 


Q INVENTEUR (S) 




Les inventeurs sont les demandeurs 


□ Oui 

0 Non Dans ce cas fournir une designation d'inventeur(s) separee 


□ RAPPORT DE RECHERCHE 


Uniquement pour une demande de brevet (y compris division et transformation) 


Etablissement immediat 
ou etablissement differe 


H 

□ 


Paiement echelonne de la redevance 


Paiement en trois versements, uniquement pour les personnes physiques 

□ Oui 

□ Non 


□ REDUCTION DU TAUX 
DES REDEVANCES 


Uniquement pour les personnes physiques 

□ Requise pour la premiere fois pour cette invention (jaimhvun arts de non-imposition ) 

□ Requise anterieurement a ce depot (joindiv une co/n'e de hi decision dad mission 
fHiur cette i mention ou indUfuersa reference): 




Si vous avez utilise I'imprime «Suite», 
indiquez le nombre de pages jointes 


0 




EE SIGNATURE DU DEMANDEUR 

OU DU MANDATAIRE S* si 
(Nom et qua lite du signataire) // \Z 

CORLU Bernard C/> 
(Mandataire) 


VISA DE LA PREFECTURE 
OU DE L'INPI 



La loi n°78-17 du 6 janvier 1978 relative a I'informatique, aux fichiers et aux liberies s'applique aux reponses faites a ce formulaire. 
Elle garantit un droit d'acces et de rectification pour les donnees vous concernant aupres de I'INPI. 
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IISPI 



BREVET DIMVENTION 



DEPARTEMENT DES BREVETS 

26 bis. rue de Saint Petersbourg 
75800 Paris Cedex 08 

Telephone : 01 53 04 53 04 Telecopie : 01 42 94 86 54 



CERTIFICAT WTILITE 

Code de la propriete intellectuelle - Uvre VI 

DESIGNATION D'INVENTEUR(S) Page N° . A / A . 
(Si le demandeur n'est pas I'inventeur ou I'umque inventeur) 

Cet imprime est a remplir lisiblement a I'encre noire 



N° 11235-02 



08 113W/260899 



Vos references pour ce dossier 

(faatltatif) 


FR 3884/BC 


N° D'ENREGISTREMENT NATIONAL 





TITRE DE L'INVENTION (200 caracteres ou espaces maximum) 

Proced6 de securisation d'un langage du type k donnees typees, notamment dans un 
systeme embarqu6 et syst&me embarqu6 de mise en oeuvre du proc6d6. 



LE(S) DEMANDEUR(S) : 



BULL CP8 

BP 45 - 68, route de Versailles 
78430 LOUVECIENNES - FRANCE 



DESIGNE(NT) EN TANT QU'INVENTEUR(S) : (Indiquez en haut a droite «Page N° 1/1» S'il y a plus de trois inventeurs, 
utilisez un formulaire identique et numerotez chaque page en indiquant le nombre total de pages). 



Nom 


Fougeroux 


Prenoms 


Nicolas 


Adresse 


Rue 


6 square Bainville 


Code postal et ville 


78150 | LE CHESNAY - FRANCE 


Societe d'appartenance (jhailtatij) 




Nom 


liameau 


Prenoms 


Patrice 


Adresse 


Rue 


18 rue Belle Feuille 


Code postal et viile 


92100 | BOULOGNE BILLANCOURT - FRANCE 


Societe d'appartenance (faatltatif) 




Nom 


Landier 


Prenoms 


Olivier 


Adresse 


Rue 


138 avenue Felix Faure 


Code postal et ville 


75015 PARIS -FRANCE 


Societe d'appartenance (faatltatif) 




DATE ET SIGNATURE(S) 
DU (DES) DEMANDEUR(S) 
OU DU MANDATAIRE 
(Nom et qualrte du signataire) 


Louveciennes, le 29 mai 200p^>^ ~? 
CORLU Bernard (Mandataire)/^ 



La loi n°78-17 du 6 janvier 1978 relative a I'informatique, aux fichiers et aux libertes s'applique aux reponses faites a ce formulaire. 
Elle garantit un droit d'acces et de rectification pour les donnees vous concernant aupres de I'lNPI. 
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PCT 



REQUETE 



Le soussigne requiert que la presente demande 
internationale soit traitee conformement au Traite de 
cooperation en matiere de brevets. 



Reserv<3^^FTice recepteur 



Demande internationale n° 



Date du depot international 



Nom de PorTice recepteur et "Demande Internationale PCT' 



Reference du dossier du deposant ou du mandataire (facultatif) 
(12 caracteres au maximum) PCT 3884/BC 



Cadre o- 1 TITRE DE L'INVENTION ^ s6curlsatlon d « un langa ge du type a donntes typees, 
notamment dans un systeme embarque et systeme embarqu6 de mise en ceuvre du proced6. 



Cadre n 8 11 DEPOSANT 




. — ? indigiii — 

n est indique ci-dessous.) 

BULL CP8 

68, route de Versailles 
BP 45 

78430 LOUVECIENNES 
FRANCE 



deposant < 



morale, designation 
tie nom du pays. Lepays de 
i domicile si aucun domicile 



□ 



Cette personne est aussi 
inventeur. 



n ° dc,6, *$3)1 39.66.61,76 



n-deta*^ 39 66 43 36 



n° de teleimprimeur 



Nationalite (nom de 1'Etat) : FRANCE 



Domicile (nom de l*Etaff RANCE 



Cette personne est 
deposant pour : 



□ tous les Etats 
design es 



di~\ tous, les Etats designes sauf 
[ I les Etats-Unis d'Amerique 



□ les Etats-Unis d'Amerique I 1 les Etats indiques dans 
seulement I 1 le cadre supplemental 



Cadre n° III AUTRE(S) DEPOSANT(S) OU ( AUTRE(S)) INVENTEUR(S) 



Nom et adresse : (Nom defamille suivi du prenom; pour une personne morale, designa ion 
qfflcielle complete. L 'adresse doit comprendre le code postal zt le n omdupay^^ 
radresse indiquee dans ce cadre est I 'Etat ou le deposant a son domicile si aucun domicile 
n est indique ci-dessous.) 

Fougeroux Nicolas 
6 square Bainville 
78150 LE CHESNAY 
FRANCE 



Cette personne est : 

| J deposant seulement 

{X | deposant et inventeur 

| | inventeur seulement 
(Si cette case est cochee 
ne pas remplir la suite.) 



Nationalite (nom de PEtat) : FRANCE 



Domicile (nom de TEtat) : 



FRANCE 



Cette personne est 
deposant pour 



□ tous les Etats I 1 tous les Etats design es sauf 
designes | I les Etats-Unis d'Ameri que 



ales Etats-Unis d'Amerique | 1 les Etats indiaues dans 
seulement | I le cadre supplemental 



|~"?^ D'autres deposants ou inventeurs sont indiques sur une feuille annexe. 



Cadre n' IV MANDATAIRE OU REPRflSENTANT COMMUN; OU ADRESSE POUR LA CORRESPONDANCE 



La personne dont Tidenu'te est donnee ci-dessous est/a ete designee pour agir au nom du ou fX"| mandataire [""] representant commun 
des deposants aupres des autorites intemationales competentes, comme: I » 



Nom et adresse : (Nom defamille suivi du prenom- pour une personne morale, designation oficielle 
complete. L 'adresse doit comprendre le code postal et le nom du pays.) 



complete.' 

BULL S.A 
CORLU Bernard 

PC 62A24 / 68, route de Versailles -BP45 
F- 78434 LOUVECIENNES Cedex (FRANCE) 



n° de telephone 

(33) 1 39.66.61.76 



n° de telecopies 

(33) 1 39.66.43.36 



n° de teleimprimeur 



□ Adresse pour la correspondance : cocher cette case lorsque aucun rnandataire ni represents ^^^J^^J^^^ 16 
et qu^l'JSpace ci-dessu£est utilise pour indiquer une adresse speciale a laquelle la correspondance doit etre envoyee. 



Formulaire PCT/RO/101 (premiere feuille) (juillet 1998; reimpression juillet 2000) 



Voir les notes relatives au formulaire de requite 
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| Suite du cadre n* III AUTRE(S) DfcPOSANT(S) OU (AUTRJE(S)) INVENTEUR(S) 


Si aucun des sous-cadres suivants n 'est utilise, cettefeuiUe ne doit pas etre incluse dans la requite. 


1 xirtm oHrpccp - A/nm fnmillf cii/vi nrenom • oour une personne morale, designation 
officielle complete. L'adresse doit comprendre le code postal et le nom du pays, he pays de 
radresse indiquee dans ce cadre est I 'Etat ou le deposant a son domicile si aucun domicile 

1 n 'est indique ci-dessous.) 

Landier Olivier 

138 avenue Felix Faure 

75015 PARIS 

FRANCE 


Cette personne est : 

[ J | deposant seulement 

| deposant et inventeur 

| | inventeur seulement 
(Si cette case est cochee, 
ne pas remplir la suite.) 


Nationalite (nomde !*Etat)FRANCE 


Domicile (nom de l'Etat) : hKAJNUJfc, 


I Cette personne est I 1 tous les Etats | I tous les Etats designes sauf K~| |es Etats-Un 

1 deposant pour : 1 1 designes 1 1 les Etats-Unis d'Amerique 1 1 seulement 


s d'Amerique 1 1 les Etats indiques dans 
1— J le cadre supplementaire 


Nom et adresse : (Norn defamille suivi du prenom; pour une personne morale, designation 
officielle complete. L 'adresse doit comprendre le code postal et le nom du pays. Lepaysde 
radresse indiquee dans ce cadre est I Etat ou le deposant a son domicile si aucun domicile 
1 n 'est indique ci-dessous.) 

§ Hameau Patrice 
18 rue Belle Feuilte 

921 00 BOULOGNE BILLANCOURT 

I FRANCE 


Cette personne est : 

|° | deposant seulement 

{ deposant et inventeur 

j 1 inventeur seulement 
(Si cette case est cochee, 
ne pas remplir la suite.) 


Nationalite (nom de V Etat) : FRANCE 


Domicile (nom de l'Etat) : rKAJNL/ii 




Nom et adresse : (Nom defamille suivi du prenom; pour une personne morale, designation 
officielle complete. L 'adresse doit comprendre le code postal et le nom du pays. Lepays de 
radresse indiquee dans ce cadre est I Etat ou le deposant a son domicile si aucun domicile 
I n 'est indique ci-dessous.) 


Cette personne est : 
|T~] deposant seulement 

| [ deposant et inventeur 

| | inventeur seulement 

(Si cette case est cochee 
ne pas remplir la suite.) 


I Nationalite (nom de l'Etat) : 


Domicile (nomde PEtat) : 


Cette personne est I 1 tous les Etats I 1 tous les Etets designes sauf | 1 1« ; Etats -U 

1 deposant pour : 1 1 designes | I les Etats-Unis d'Amenque I 1 seulement 


nis d'Amerique I 1 les Etats indiques dans 

| I le cadre supplementaire 


Nom et adresse : (Nom defamille suivi du prenom; pour une personne morale, designation 
officielle complete. L'adresse doit comprendre \le code postal et le nomdu pays. Lepaysde 
radresse indiquee dans ce cadre est I Etat ou le deposant a son domicile si aucun domicile 
I n 'est indique ci-dessous.) 


Cette personne est : 

f [ deposant seulement 

| | deposant et inventeur 

inventeur seulement 
(Si cette case est cochee, 
ne pas remplir la suite) 


Nationalite (nom de l'Etat) : 


Domicile (nom de l'Etat) : 




I J | D'autres deposants ou inventeurs sont indiques sur une autre feuille annexe. 



Foimulaire PCT/RO/101 (feuille annexe) (juiltet 1998; reimpression juillet 2000) Voir les notes relatives auformulaire de requite 
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Feuille n° 



..3... PCT/ERj 1/01506 



Cadre n» V DESIGNATION D'ETATS 



Les designations suivantes sont fait^^WDrmement a la regie 4.9.a) (cocker les cases app^^^s; une au moins doit I'etre) : 
Brevet regional 

□ AP Brevet ARIPO : GH Ghana,. GM Gambie, KE Kenya, LS Lesotho, MW Malawi, MZ Mozambique, SD Soudan, 

SL Sierra Leone, SZ Swaziland, TZ Republique-Unie de Tanzanie, UG Ouganda, ZW Zimbabwe et tout autre Etat qui est un Etat 
contractant du Protocole de Harare et du PCT 

□ EA Brevet eurasien: AM Armenie, AZ AzerbaTdjan, BY Belarus, KG Kirghizistan, KZ Kazakhstan, MD Republique de Moldova, 

RU Federation de Russie, TJ Tadjikistan, TM Turkmenistan et tout autre Etat qui est un Etat contractant de la Convention sur 
le brevet eurasien et du PCT 

(S0 EP Brevet europeen : AT Autriche, BE. Belgique, CH et LI Suisse et Liechtenstein, CY Chypre, DE Allemagne, 
DK Danemark, ES Espagne, FI Finlande, FR France, GB Royaume-Uni, GR Grece, IE Irlande, IT Italie, 
LU Luxembourg, MC Monaco, NL Pays-Bas, PT Portugal, SE Suede et tout autre Etat qui est un Etat contractant de la 
Convention sur le brevet europeen et du PCT FT ft. T«^CL^*c( 

□ OA Brevet OAPI : BF Burkina Faso, BJ Benin, CF Republiqa^centrafricaine, CG Congo, CI Cote d'lvoire, 

CM Cameroun, GA Gabon, GN Guinee, GW Guinee-Bissau, ML Mali, MR Mauritanie, NE Niger, SN Senegal, 
TD Tchad, TG Togo et tout autre Etat qui est un Etat membre de TOAPI et un Etat contractant du PCT (si une autre forme 

de protection ou de traitement est souhaitee, le preciser sur la ligne pointillee) 

Brevet national (si une autre forme de protection ou de traitement est souhaitee, le preciser sur la ligne pointillee) : 

□ AE Emirats arabes unis □ LC Sainte-Lucie 

□ AG Antigua-et-Barbuda □ LK Sri Lanka 

□ AL Albanie □ LR Liberia 

□ AM Armenie □ LS Lesotho 

□ AT Autriche □ LT Lituanie 

12" AU Australie □ LU Luxembourg 

□ AZ Azerbaidjan □ LV Lettonie 

□ BA Bosnie-Herzegovine □ MA Maroc 

□ BB Barbade □ MD Republique de Moldova 

□ BG Bulgarie □ MG Madagascar 

□ BR Bresil D MK Ex-Republique yougoslave de Macedoine 

□ BY Belarus □ MN Mongolie 

□ BZ Belize □ MW Malawi 

□ CA Canada □ MX Mexique 

□ CH et LI Suisse et Liechtenstein □ MZ Mozambique 
£jCN Chine □ NO Norvege 

□ CR Costa Rica □ NZ Nouvelle-Zelande 

□ CU Cuba □ PL Pologne 

□ CZ Republique tcheque □ PT Portugal 

□ DE Allemagne □ RO Roumanie 

□ DK Danemark O RU Federation de Russie 

□ DM Dominique □ SD Soudan 

□ DZ Algerie 7 □ SE Suede 

□ EE Estonie □ SG Singapour 

□ ES Espagne □ SI Slovenie 

□ FI Finlande □ SK Slovaquie 

□ GB Royaume-Uni □ SL Sierra Leone 

□ GD Grenade □ TJ Tadjikistan 

□ GE Georgie □ TM Turkmenistan 

□ GH Ghana □ TR Turquie 

□ GM Gambie □ TT Trinite-et-Tobago 

□ HR Croatie □ TZ Republique-Unie de Tanzanie 

□ HU Hongrie □ UA Ukraine 

□ ID Indonesie □ UG Ouganda 

□ IL Israel • ^ US Etats-Unis d'Amerique 

□ IN Inde □ UZ OuzbeTcistan 

□ IS Islande □ VN Viet Nam 

;E(JP Japon □ YU Yougoslavie 

□ KE Kenya □ ZA Afrique du Sud 

□ KG Kirghizistan □ ZW Zimbabwe 

□ KP Republique populaire democratique de Coree Case reserv6epour la designation d'Etats qui sont devenus parties au 

U KR Republique de Coree . PCT apres la publication de la presente feuille : 

□ KZ Kazakhstan □ 

Declaration concernant les designations de precaution : outre les designations faites ci-dessus, le deposant fait aussi conformement 
a la regie 4.9.b) toutes les designations qui seraient autorisees en vertu du PCT, a Texception de toute designation indiquee dans le cadre 
suppl^mentaire comme ^tant exclue de la portee de cette declaration. Le deposant declare que ces designations additionnelles sont 
faites sous reserve de confirmation et que toute designation qui n'est pas confirmee avant V expiration d'un d61ai de 1 5 mois a compter 
de la date de priority doit tee consideree comme retiree par le deposant a V expiration de ce delai. (La confirmation (y compris les taxes) 
doit parvenira I * office recepteur dans le delai del 5 mois.) 



Formulaire PCT/RO/101 (deuxieme feuille) (juillet 2000) Voir les notes relatives auformulaire de requite 
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Feuille n° 



pct/ er: i / 0 1 5 0 6 



Cadre n° VI 



REVENDICATIQ 



Date de depot 
. de la demande anterieure 
(jour/mois/annee) 



PRIORITE 



jmero 

de la demande anterieure 



Lorsque la d< 



leman^Bnt 



^nitres revendications de priorite sont 
quees dans le cadre supplementaire. 



terieure est une : 



demande nationale : 

pays 



demande regionale : 
office regional 



demande Internationale : 
office recepteur 



( ?7 mai 2000 
(17.05.2000) 



00 06882 



FRANCE 



(2) 



(3) 



L'offjce recepteur est prie de preparer et de transmettre au Bureau international une copie certifiee conforme de la ou des demandes 
anterieures (settlement si la demande anterieure a ete deposee aupres de I 'office qui, aux fins de 

la presente demande Internationale, est I 'office recepteur) indiquees ci-dessus au(x) point(s) : __j 



* Si la demande anterieure est une demande ARIPO, il est obligatoire d 'indiquer dans le cadre supplementaire au mains un pays partie a la C 
de Paris pour la protection de la propriete industrielle pour lequel cette demande anterieure a ete deposee (regie 4. IQ.bJii)). Voir le cadre supph 



partie a la Convention 
\ementaire. 



Cadre n° VII ADMINISTRATION CHARGfcE DE LA RECHERCHE INTERNATIONALE 



Choix de ('administration chargee de la recherche 
Internationale (ISA) (si plusieurs administrations 
chargees de la recherche Internationale sont competentes 
pour proceder a la recherche Internationale, indiquer 
I 'administration choisie; le code a deux lettres peut etre 
utilise) : 

ISA/ 



Demande d'utilisation des resultats d'une recherche anterieure; mention de 
cette recherche (si une recherche anterieure a ete effectuee par I 'administration 
chargee de la recherche Internationale ou demandee a cette derniere) : 

Date (jour/mois/annee) Numero Pays (ou office regional) 

17.05.00 00 06882 FR 
FA FA 592408 



Cadre n« VIII BORDEREAU; LANGUE DE DEPOT 



La presente demande Internationale contient 
le nombre de feuilles suivant : 



requete 

description (sauf partie reservee 
au listage des sequences) 

revendications 

abrege 

dessins 

partie de la description reservee 
au listage des sequences 

Nombre total de feuilles 



04 

01 
04 



Le ou Ies elements coches ci-apres sont joints a la presente demande intemationale 

1 . H feuille de calcul des taxes 

2. □ pouvoir distinct signe 

3. JSl copie du pouvoir general; numero de reference, le cas echeant : G PAO \f(X,~}5 

4. □ explication de V absence d'une signature 

5. § document(s) de priorite indique(s) dans le cadre n° VI au(x) point(s) : 1 

6. □ traduction de la demande intemationale en (langue) : 

7. □ indications separees concemant des micro-organismes ou autre materiel 

biologique deposes 

8. □ listage des sequences de nucleotides ou d'acides amines sous forme 

-dechiffrable par ordinateuiR a pp 0r t de Recherche 

9. £fl autres elements (preciser) : 



Figure des dessins qui 3 
doit accompagner V abrege : 


Langue de depdt de la FRANCAIS 
demande intemationale : 


Cadre n° IX SIGNATURE DU DEPOSANT OU DU MANDATAIRE 



A cote de chaque signature, indiquer le nom du signataire et. si cela n 'apparait pas clairement a la lecture de la requete, a quel titre I 'interesse signe. 

-v — 



CORLU Bernard (mandataire) 

u. 

ysHeserve a Toffice re 




1 . Date effective de reception des pieces suppo: 
constituer la demande intemationale : 



rm'm 



3. Date effective de reception, rectifiee en raison de la reception ulte- 
rieure, mais dans les delais, de documents ou de dessins completant ce 
qui est suppose constituer la demande intemationale : 



4. Date de reception, dans les delais, des corrections 
demandees selon I" article 1 1 .2) du PCT : 



2. Dessins : 
| | recus: 



□ 



non recus : 



5. Administration chargee de la recherche TC . , 
intemationale (si plusieurs sont competentes) : loA / 



□ Transmission de la copie de recherche dirTeree 
jusqu'au paiement de la taxe de recherche. 



Reserve au Bureau international 



Date de reception de l'exemplaire 
original par le Bureau international : 



Formulaire PCT/RO/101 (derniere feuille) Quillet 1998; reimpression juillet 2000) 



Voir les notes relatives au formulaire de requete 



This Page Blank (uspto) 



TRAITE D^pOPERATION EN MATIER^^ BREVETS 



WO 01/88705 
PCT/FR01/01506 



Expediteur: le BUREAU INTERNATIONAL 



AVIS INFORMANT LE DEPOSANT DE LA 
COMMUNICATION DE LA DEMANDE 
INTERNATIONALE AUX OFFICES DESIGNES 

(regie 47.1.c), premiere phrase, du PCT) 



Oestinataire: 

CORLU, Bernard 
Bull S.A 
PC 62A24 
68, a route de Vers^ 
Boite postale 45 
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RENSEIGNEMENTS CONCERNANT LES DELAIS DANS LESQUELS DOIT ETRE ABORDEE 

LA PHASE NATIONALE 



II est rappele au deposant qu'il doit aborder la "phase nationale" aupres de chacun des offices designes indiques sur la 
notification de la reception de I'exemplaire original (formulaire PCT/IB/301) en payant les taxes nationales et en remettant les 
traductions, telles qu'eiles sont prescrites par les legislations nationales. 

Le delai d'accomplissement de ces actes de procedure est de 20 MOIS a compter dela date de priorite ou, pour les Etats 
designes qui ont ete elus par ie deposant dans une demande d'examen preliminaire international ou dans une election ulterieure, 
de 30 MOIS a compter de la date de priorite, a condition que cette election ait ete effectuee avant I'expiration du 19e mois a 
compter de la date de priorite. Certains offices designes (ou elus) ont fixe des delais qui expirent au-dela de 20 ou 30 mois a 
compter de la date de priorite. D'autres offices accordent une prolongation des delais ou un delai de grace, dans certains cas 
moyennant le paiement d'une taxe supplemental. 

En plus de ces actes de procedure, le deposant devra dans certains cas satisfaire a d'autres exigences particulieres 
applicables dans certains offices. II appartient au deposant de veiller a remplir en temps voulu les conditions requises pour 
I'ouverture de la phase nationale. La majorite des offices designes n'envoient pas de rappei d Papproche de la date limite pour 
aborder la phase nationale. 

Des informations detail lees concernant les actes de procedure a accompli r pour aborder la phase nationale aupres de 
chaque office designe, les delais applicables et la possibility d'obtenir une prolongation des delais ou un delai de grace et toutes 
autres conditions applicables figurent dans le volume II du Guide du deposant du PCT. Les exigences concernant le depot d'une 
demande d'examen preliminaire international sont exposees dans le chapitre IX du volume I du Guide du deposant du PCT. 

GRet ES sont devenues liees par le chapitre II du PCT le 7 septembre 1996 et le 6 septembrel997, respectivement, et 
peuvent done etre elues dans une demande d'examen preliminaire international ou dans une election ulterieure presentee le 7 
septembre 1996 (ou a une date posterieure) ou le 6 septembre 1997 (ou a une date posterieure), respectivement, quelle que soit 
la date de depot de la demande international (voir le second paragraphe, ci-dessus). 

Veuillez noter que seul un deposant qui est ressortissant d'un Etat contractant du PCT lie par le chapitre II ou qui y a 
son domicile peut presenter une demande d'examen preliminaire international. 



CONFIRMATION DES DESIGNATIONS FAITES PAR MESURE DE PRECAUTION 



Seuies les designations expresses faites dans la requete conformement a la regie 4.9. a) figurent dans la presente 
notification. II est important de verifier si ces designations ont ete faites correctement. Des erreurs dans les designations peuvent 
etre corrigees lorsque des designations ont ete faites par mesure de precaution en vertu de la regie 4.9. b). Toute designation 
ainsi faite peut etre confirmee conformement aux dispositions de la regie 4.9. c) avant I'expiration d'un delai de 1 5 mois a 
compter de la date de priorite. En I'absence de confirmation, une designation faite par mesure de precaution sera consideree 
comme retiree par le deposant. II ne sera adresse aucun rappei ni invitation. Pour confirmer une designation , il faut deposer une 
declaration pr6cisant I'Etat design^ concern^ (avec I'indication de la forme de protection ou de traitement souhaitee) et payer les 
taxes de designation et de confirmation. La confirmation doit parvenir a I'office recepteur dans le delai de 15 mois. 



EXIGENCES RELATIVES AUX DOCUMENTS DE PRIORITE 



Pour les deposants qui n'ont pas encore satisfait aux exigences relatives aux documents de priorite, il est rappele ce qui 

suit. 

Lorsque la priorite d'une demande nationale, regionale ou internationale anterieure est revendiquee, le deposant doit 
presenter une copie de cette demande anterieure, certifiee conforme par ('administration aupres de laquelle elle a ete deposee 
("document de priorite"), a I'office recepteur (qui la transmettra au Bureau international) ou directement au Bureau international, 
avant I'expiration d'un delai de 1 6 mois a compter de la date de priorite, etant entendu que tout document de priorite peut etre 
presente au Bureau international avant la date de publication de la demande internationale, auquel cas ce document sera repute 
avoir ete regu par le Bureau international le dernier jour du delai de 16 mois (regie 17.1. a)). 

Lorsque le document de priorite est delivre par I'office recepteur, le deposant peut, au lieu de presenter ce document, 
demander a I'office recepteur de le preparer et de le transmettre au Bureau international. La requete a cet effet doit etre 
formulee avant I'expiration du delai de 16 mois et peut etre soumise au paiement d'une taxe (regie 17.1. b)). 

Si le document de priorite en question n'est pas fourni au Bureau international, ou si la demande adressee a I'office recepteur 
de preparer et de transmettre le document de priorite n'a pas ete faite (et la taxe correspondante acquittee, le cas echeant) 
avant I'expiration du delai applicable mentionne aux paragraphes precedents, tout Etat designe peut ne pas tenir compte 
de la revendication de priorite; toutefois, aucun office designe ne peut decider de ne pas tenir compte de la revendication de 
priorite avant d'avoir donne au deposant la possibility de remettre le document de priorite dans un delai raisonnable en I'espece. 

Lorsque plusieurs priorites sont revendiquees, la date de priorite a prendre en consideration aux fins du calcul du delai de 
16 mois est la date du depot de la demande la plus ancienne dont la priorite est revendiquee. 
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(57) Abstract: The invention 
concerns a method and a microchip 
(8) integrated system for executing 
securely a sequence of instructions 
of a computer application in the 
form of objects or typed data, in 
particular written in JAVA language. 
The storage unit (I) is arranged 
into a first series of elementary 
stacks (2, 3) for recording the 
instructions. The method consists 
in associating with each data or 
typed object one or several so-called 
typing bits specifying the type. 
Said bits are recorded in a second 
series of stacks (4, 5) in one-to-one 
relationship with the stacks (2, 3) 
of the first series. Before executing 
the instructions of predetermined 
types, a continuous verification is 
carried out, prior to execution of 
said instructions, of the conformity 
between a type mentioned 
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Publiee : 

— avec rapport de recherche Internationale 



En ce qui concerne les codes a deux lettres et autres abrexia- 
tions. se referer aux "Notes explicatixes relatives aux codes et 
abreviations" figurant au debut de chaque numero ordinaire de 
la Gazette du PCX 



in the instructions and an expected type, indicated by the typing bits. In case of non -conformity, the execution is stopped. 

(57) Abrege : L'invention concerne un procede et un systeme embarque a puce electronique (8) pour I' execution securisee d ? une 
sequence d instructions d ; une application informatique se presentant sous la forme d 'objects ou de donnees typees, notamment ecrite 
en langage "JAVA". La memoire (1) est organisee en une premiere serie de piles elementaires (2, 3) pour Tenregistrement des ins- 
tructions. On associe a chaque donnee ou objet type un ou plusieurs bits dits de typage specifiant le type. Ces bits sont enregistres 
dans une deuxieme sene de piles elementaires (4, 5), en relation biunivoque avec les piles (2, 3) de la premiere serie Avant Texe- 
cution d instructions de types predetermines, ii est procede a une verification en continu, prealable a l ? execution de ces instructions 
de la concordance entre un type indique par celles-ci et un type attendu, indique par les bits de typage. En cas de non-concordance 
1 execution et stoppee. 
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PROCEDE DE SECURISATION D'UN LANGAGE DU TYPE A DONNEES 
TYPEES, NOTAMMENT DANS UN SYSTEME EMBARQUE ET SYSTEME 
EMBARQUE DE MISE EN CEUVRE DU PROCEDE 

L'invention concerne un procede de securisation dynamique d'un 
langage du type a donnees typees, notamment pour un systeme embarque a 
puce electronique. 

L'invention concerne encore un systeme embarque a puce 
5 electronique pour la mise en oeuvre du procede. 

Dans le cadre de Invention, le terme "systeme embarque" doit etre 
compris dans son sens le plus general. II concerne notamment toutes sortes 
de terminaux legers munis d'une puce electronique, et plus particulierement 
les cartes a puce proprement dites. La puce electronique est munie de 
10 moyens d'enregistrement et de traitement de donnees numeriques, par 
exemple un microprocesseur pour ces derniers moyens. 

Pour fixer les idees, et sans que cela limite en quoi que ce soit sa 
portee, on se placera ci-apres dans le cas de ^application preferee de 
('invention, a savoir les applications a base de cartes a puce, sauf mention 
15 contraire. 

De meme, bien que divers langages informatiques, tels les 
langages "ADA" ou "KAMEL" (tous deux etant des marques deposees), sont 
du type dit a donnees ou objets types, un des langages les plus utilises dans 
le domaine prefere de Invention etant le langage de type objet "JAVA" 

20 (marque deposee), ce langage sera pris comme exemple ci-apres, pour 
decrire en detail le procede de Pinvention. 

Enfin, le terme "securisation" doit lui aussi etre compris dans un 
sens general. Notamment, il concerne aussi bien ce qui a trait au concept de 
confidentialite des donnees manipulees qu'au concept d l integrite, materielle 

25 et/ou logicielle, des composants presents dans le systeme embarque. 
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Avant de decrire plus avant I'invention, il est tout d'abord utile de 
rappeler brievement les principales caracteristiques du langage "JAVA", 
notamment dans un environnement du type carte a puce. 

Ce dernier langage presente en particulier I'avantage d'etre 
5 multiplateformes : il suffit que la machine dans laquelle s'execute 
I'application ecrite en langage "JAVA" soit munie d'un minimum de 
ressources informatiques specifiques, notamment d'une piece de logiciel 
appele "machine virtuelle JAVA" pour ('interpretation d'une suite de 
sequences d' "opcodes" d'instructions de 8 bits, appelees "bytecode" ou "p- 

io code" (pour "program code" ou code programme). Le "p-code" est enregistre 
dans des positions de memoire des moyens d'enregistrement de donnees 
precites. Plus precisement, dans le cas du langage "JAVA", la zone occupee 
par les positions de memoire, d'un point de vue logique, se presente sous 
une configuration connue sous le nom de pile. 

15 Dans le cas d'une carte a puce, celle-ci integre la "machine virtuelle 

JAVA" (enregistree dans ses moyens de memoire) et fonctionne en 
interpretant un langage base sur la sequence d'opcodes precitee. Le code 
executable ou "p-code" resulte d'une compilation prealable. Le compilateur 
est agence pour que le langage transforme obeisse a un format determine et 

20 respecte un certain nombre de regies fixees a priori. 

Les "opcodes" peuvent recevoir des valeurs d'elements les suivants 
dans une sequence du "p-code", ces elements sont alors appeles 
parametres. Les opcodes peuvent aussi recevoir des valeurs en provenance 
de la pile. Ces elements constituent alors des operandes. 

25 Selon une autre caracteristique du langage "JAVA", il est mis en 

oeuvre des elements connus sous les noms de "classes" et de "methodes". 
Lors de I'execution d'une methode donnee, la machine virtuelle retrouve le 
"p-code" correspondant. Ce "p-code" identifie des operations specifiques a 
effectuer par la machine virtuelle. Une pile particuliere est necessaire pour 

30 le traitement de variables dites locales, d'operations arithmetiques ou pour 
I'invocation d'autres methodes. 
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Cette pile sert de zone de travail pour la machine virtuelle. Pour 
optimiser les performances de la machine virtuelle, la largeur de la pile est 
generalement fixee pour un type primitif donne. 

Dans cette pile deux grands types d'objets peuvent etre manipules : 
5 - des objets de type dit "primitif", ceux connus sous les denominations 
"int" (pour entier long : 4 octets), "short" (pour entier court : 2 octets), 
"byte" (octet), "boolean" (objet booleen) ; et 

des objets de type dit "reference" (tableaux d'objets de type primitif, 
instances de classes). 
10 La difference fondamentale entre ces deux types d'objets est que 

seule la machine virtuelle attribue une valeur a des objets de type reference 
et les manipule. 

Les objets references peuvent etre vus comme des pointeurs vers 
des zones memoires de la carte a puce (references physiques ou logiques). 
15 Le langage "JAVA", dont les principals caracteristiques viennent 

d'etre succinctement rappelees, se prete particulierement bien aux 
applications mettant en jeu des interconnexions avec le reseau Internet et 
son grand succes est d'aiileurs lie au fort developpement des applications 
Internet. 

20 D'un point de vue securite, il presente aussi un certain nombre 

d'avantages. Tout d'abord, le code executable ou "p-code" resulte d'une 
compilation prealable. Le compilateur peut done etre agence, comme il a ete 
indique, pour que le langage transforme obeisse a un format determine et 
respecte un certain nombre de regies fixees a priori 

25 Une de ces regies est qu'une application donnee soit confinee a 

Tinterieur de ce qui est appele une "sand box" (ou "boite noire"). Les 
instructions et/ou donnees associees a une application determinee sont 
memorisees dans des positions de memoire des moyens d'enregistrement 
de donnees. Dans le cas du langage "JAVA", d'un point de vue logique, la 

30 configuration de ces moyens d'enregistrement de donnees prend la forme 
d'une pile. Le confinement dans une "sand box" signifie en pratique que les 
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instructions precitees ne peuvent pas adresser des positions memoires en 
dehors de celles affectees a ladite application, sans y etre autorisees 
expressement. 

Cependant, une fois charge en memoire, des problemes de securite 
5 peuvent se poser si le "p-code" a ete altera ou si son format n'a pas 
respecte les specifications de la machine virtuelle. Aussi, dans I'art connu, 
notamment lorsqu'il s'agit d'applications, par exemple des "applets" 
(appliquettes), telechargees via le reseau Internet, le code compile, c'est-a- 
dire le "p-code" est verifie par la machine virtuelle. Cette derniere est 

10 habituellement associee a un navigateur de type "WEB" dont est muni le 
terminal connecte au reseau Internet. Pour ce faire, la machine virtuelle est 
elle-meme associee a une piece de logiciel particuliere ou verificateur. 

Cette verification peut s'effectuer en mode dit "off-line", c'est-a-dire 
hors connexion, ce qui ne penalise pas le traitement de I'application, 

15 notamment d'un point de vue coQt de communication. 

On est ainsi sur, apres que la verification soit effectuee, que le "p- 
code" n'est pas endommage et est conforme au format et aux regies 
preetablis. On est aussi sur, dans ces conditions, que lors de Pexecution du 
"p-cpde", il n'y aura pas de deterioration du terminal dans lequel il s'execute. 

20 Cependant, ce procede n'est pas sans inconvenients, en particulier 

dans le cadre des applications visees preferentiellement par I'invention. 

Tout d'abord, le verificateur precite necessite a lui seul une quantite 
de memoire relativement importante, de I'ordre de plusieurs MO. Cette 
valeur elevee ne presente pas de problemes particuliers si le verificateur est 

25 enregistre dans un micro-ordinateur ou un terminal similaire disposant de 
ressources memoires elevees. Cependant, lorsque Ton envisage d'utiliser un 
terminal de traitement de donnees possedant des ressources informatiques 
plus limitees, a fortiori une carte a puce, il n'est pas envisageable, d'un point 
de vue pratique, compte tenu des technologies actuellement disponibles, 

30 d'implementer le verificateur dans ce type de terminal. 
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On doit egalement noter que la verification est d'un type que Ton 
peut qualifier de "statique", car effectuee une fois pour toute, avant 
I'execution du "p-code". Lorsqu'il s'agit d'un terminal du type micro- 
ordinateur, notamment iorsque ce dernier est maintenu deconnecte lors de 

5 I'execution du "p-code" verifie au prealable, cette derniere caracteristique ne 
pose pas de problemes particuliers. En effet, il n'existe pas de risques 
importants, d'un point de vue securite, car le terminal reste habituellement 
sous le controle de son operateur. 

Tel n'est pas le cas pour un systeme embarque mobile, notamment 

10 pour une carte a puce. En effet, si le "p-code", meme verifie, est ensuite 
charge dans les moyens d'enregistrement de donnees de la carte a puce, il 
peut subir a posteriori des alterations. En general, la carte a puce, ce par 
nature, n'est pas destinee a demeurer en permanence dans le terminal a 
partir duquel I'application a ete chargee. A titre d'exemple non limitatif, la 

15 carte a puce peut etre soumise a un rayonnement ionisant qui altere 
physiquement des positions de memoire. II est possible egalement d'alterer 
le "p-code" au moment de son telechargement dans la carte a puce, a partir 
du terminal. 

II s'ensuit que, si le "p-code" est altere, notamment dans un but 
20 malveillant, il est possible d'effectuer une operation dite de "dump" 
(duplication) de zones de memoires et/ou de mettre en peril le bon 
fonctionnement de la carte a puce. II devient ainsi possible, par exemple, et 
malgre la disposition dite de "sand box" precitee, d'avoir acces a des 
donnees confidentielles, ou pour le moins non autorisees, ou d'attaquer 
25 I'integrite d'une ou plusieurs applications presentes sur la carte a puce. 
Enfin, si la carte a puce est connectee au monde exterieur, les 
dysfonctionnements provoques peuvent se propager a I'exterieur de la carte 
a puce. 

L'invention vise a pallier les inconvenients des precedes et 
30 dispositifs de I'art connu, et dont certains viennent d'etre rappeles. 
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^invention se fixe pour but un procede de securisation dynamique 
duplications en langage du type a donnees typees dans un systeme 
embarque. 

Elle se fixe egalement pour but un systeme pour la mise en oeuvre 
5 de ce procede. 

Pour ce faire, selon une premiere caracteristique, un element 
d'information binaire comprenant un ou plusieurs bits, que Ton appellera ci- 
apres "element d'information de type", est associe a chaque objet manipule 
par la machine virtuelle, dans le cas du langage "JAVA" precite. De fagon 
10 plus generale, un element d'information de type est associe a chaque 
donnee typee manipulee dans un langage donne, du type a objets ou 
donnees types. 

Selon une autre caracteristique, les elements d'information de type 
sont stockes physiquement dans des zones de memoire particulieres des 

15 moyens de memorisation du systeme embarque a puce electronique. 

Selon une autre caracteristique encore la machine virtuelle, toujours 
dans le cas du langage "JAVA" verifie lesdits elements d'information de type 
lors de certaines operations d'execution du "p-code", telles la manipulation 
d'objet dans la pile, etc., operations qui seront precisees ci-apres. De fagon 

20 plus generale egalement, pour un autre langage, le processus est similaire 
et il est procede a une etape de verification des elements d'information de 
type. On constate done que, de fagon avantageuse, ladite verification est 
d f un type que Ton peut appeler dynamique, puisqu'effectuee en temps reel 
lors de Interpretation ou de Texecution du code. 

25 La machine virtuelle, ou ce qui en tient lieu pour un langage autre 

que le langage "JAVA", verifie, en continu et avant ladite execution d'une 
instruction ou d'une operation, que Telement d'information de type 
correspond bien au type attendu de Tobjet ou de la donnee type a manipuler. 
Lorsqu'un type incorrect est detecte, des mesures securitaires sont prises 

30 afin de proteger la machine virtuelle et/ou d'empecher toutes operations non 
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conformes et/ou dangereuses pour I'integrite du systeme embarque a puce 
electronique. 

Selon une premiere variante de realisation supplemental re du 
procede selon I'invention, lesdits elements d'information de type sont 

5 egalement utilises avantageusement pour permettent la gestion de piles de 
largeurs variables, ce qui permet d'opti miser I'espace memoire du systeme 
embarque a puce electronique, dont les ressources de ce type sont, par 
nature, limitees, comme il a ete rappele. 

Selon une deuxieme variante de realisation supplemental, 

10 cumulable avec la premiere, les elements d'information de type sont 
egalement utilises, en y adjoignant un ou plusieurs bit(s) d'information 
supplementaire(s), utilises comme "drapeau" ("flags" selon la terminologie 
anglo-saxonne), pour marquer les objets ou les donnees typees. Ce 
marquage est alors utilise pour indiquer si ces derniers elements sont 

is utilises ou non, et dans ce dernier cas, s'ils peuvent etre effaces de la 
memoire, ce qui permet egalement de gagner de la place memoire. 

L'invention a done pour objet principal un procede pour I'execution 
securisee d'une sequence destructions d'une application informatique se 
presentant sous la forme de donnees typees enregistrees dans une 

20 premiere serie d'emplacements determines d'une memoire d'un systeme 
informatique, notamment un systeme embarque a puce electronique, 
caracterise en ce que des donnees supplementaires dites elements 
d'information de type sont associes a chacune desdites donnees typees, de 
maniere a specifier le type de ces donnees, en ce que lesdits elements 

25 d'information de type sont enregistres dans une deuxieme serie 
d'emplacements de memoire determines de ladite memoire de systeme 
informatique, et en ce que, avant I'execution destructions d'un type 
predetermine, il est procede a une verification en continu, prealable a 
I'execution d'instructions predeterminees, de la concordance entre un type 

30 indique par ces instructions et un type attendu indique par lesdits elements 
d'information de type enregistres dans ladite deuxieme serie d'emplacement 
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de memoire, de maniere n'autoriser ladite execution qu'en cas de 
concordance entre lesdits types. 

L'invention a encore pour objet un systeme embarque a puce 
electronique pour la mise en oeuvre de ce procede. 
5 L'invention va maintenant etre decrite de fa<?on plus detaillee en se 

referant aux dessins annexes, parmi lesquels : 

les figures 1A a 1G illustrent les principales etapes d'une 
execution correcte d'un exemple de "p-code" dans une memoire a 
pile associee a des zones de memoire specifiques stockant des 
10 donnees dites elements d'information de type selon Tinvention ; 

les figures 2A et 2B illustrent schematiquement des etapes 
d'execution de ce meme code, mais contenant une alteration menant 
a une execution incorrecte et une detection de cette alteration par le 
procede de invention ; et 
15 - la figure 3 illustre schematiquement un systeme comprenant 

une carte a puce pour la mise en oeuvre du procede selon 
Tinvention. 

Dans ce qui suit, sans en limiter en quoi que ce soit la portee, on se 
placera ci-apres dans le cadre de Papplication preferee de Tinvention, sauf 
20 mention contraire, c ? est-a-dire dans le cas d'un systeme embarque a puce 
electronique integrant une machine virtuelle "JAVA" pour Tinterpretation de 
"p-code". 

Comme il a ete rappele dans le preambule de la presente 
description, lors de I'execution d'une methode donnee, la machine virtuelle 
25 retrouve le "p-code M correspondant. Ce "p-code" identifie des operations 
specifiques a effectuer par la machine virtuelle. Une pile particuliere est 
necessaire pour le traitement de variables dites locales, d'operations 
arithmetiques ou pour I'invocation d'autres methodes. 

La pile sert de zone de travail pour la machine virtuelle. Pour 
30 optimiser les performances de la machine virtuelle, la largeur de la pile est 
generalement fixee pour un type primitif donne. 
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Comme il a ete egalement rappele, dans cette pile deux grands 
types d'objets peuvent etre manipules : 

des objets de type dit "primitif", ceux connus sous les denominations 
"int" (pour entier long : 4 octets), "short" (pour entier court : 2 octets), 
5 "byte" (octet), "boolean" (objet booleen) ; et 

des objets de type dit "reference" (tableaux d'objets de type primitif, 
instances de classes). 

C'est ce dernier type d'objets qui pose le plus de probleme, d'un 
point de vue securite, puisqu'il existe des possibilites, comme indique 
w precedemment, de les manipuler de fagon artificielle et de creer ainsi des 
dysfonctionnements de natures diverses. 

lis existent plusieurs types d' "opcodes", et notamment : 
la creation d'un objet de type primitif (par exemple les opcodes 
denommes "bipush" ou "iconst") ; 
15 - Texecution d'operations arithmetiques sur des objets de type primitif 
(par exemple les "opcodes" denommes "iadd" ou "sadd") ; 
la creation d'un objet reference (par exemple les "opcodes" 
denommes "new", "newarray" ou "anewarray"). 
la gestion de variables locales (par exemple les "opcodes" denommes 
20 "a/oaof", "iload" ou "istore") ; et 

la gestion de variables de classes (par exemple les "opcodes" 
denommes "getstaticja" ou "putfieldj'). 
Chaque "opcode" qui utilise des objets places en pile est type afin 
de s'assurer que son execution puisse etre controlee. Generalement la(les) 
25 premiere(s) lettre(s) des "opcodes" indique(nt) le type utilise. A titre 
d'exemple, et pour fixer les idees, (la ou les premiere(s) lettre(s) etant 
graissee pour mettre en evidence cette disposition), on peut citer les 
"opcodes" suivants : 

"a/oad" pour les objets references ; 
30 - "iload" pour les entiers ; et 

"iaload" pour les tableaux d'entiers. 
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Dans ce qui suit, par mesure de simplification la "machine virtuelle 
JAVA" sera appelee JVM. 

Selon une premiere caracteristique du procede selon I'invention, 
des elements d'information de type sont stockes dans une zone memoire 
5 sous la forme, chacun, d'un ou de plusieurs bits. Chacun de ces elements 
d'information de type caracterise un objet manipule par la JVM. On associe 
notamment un element d'information de type a : 

chaque objet empile dans la zone de donnee de la pile ; 
chaque variable locale (variable dont la portee ne depasse pas le 
10 cadre d'une methode) ; et 

a chaque objet de ce qui est appele le "heap", c'est-a-dire une zone 
de memoire stockant les objets dits "reference", chaque tableau et 
chaque variable globale. 
Cette operation peut etre appelee "typage" des objets. Selon une 
15 deuxieme caracteristique du procede de I'invention, la JVM verifie le typage 
dans les cas suivants : 

lorsqu'un "opcode" manipule un objet stocke dans la pile ; 
recupere un objet dans la zone du "heap" ou dans celle des variables 
locales pour le placer en pile ; 
20 - modifie un objet dans la zone du "heap" ou dans celle des variables 
locales ; et 

lors de I'invocation d'une nouvelle methode, lorsque les operandes 
sont compares a la signature de la methode. 
Selon une autre caracteristique du procede de I'invention, la JVM 
25 verifie, avant I'execution des operations ci-dessus, que leurs types 
correspondent bien a celui attendu (c'est-a-dire ceux donnes par les 
"opcode" a effectuer). 

Dans le cas de la detection d'un type incorrect, des mesures 
securitaires sont prises afin de proteger la JVM et/ou d'empecher toutes 
30 operations illegales ou dangereuses pour I'integrite du systeme, tant d'un 
point de vue logique que materiel. 
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Pour mieux expliciter le procede selon Pinvention, on va maintenant 
le detainer en considerant un exemple particulier de code source en langage 
"JAVA". 

On suppose egalement que la JVM est associee a une pile de 32 
5 bits comportant au plus 32 niveaux et supportant les types primitifs (par 
exemple "int", "short", "byte", "boolean" et "object reference") 

Le typage de la pile, selon Tune des caracteristiques de Pinvention, 
peut alors etre realise a Paide d'elements d'information de type de longueur 
3 bits, conformement a la TABLE I placee en fin de la presente description. 
10 Les valeurs portees dans la TABLE I sont naturellement arbitraires. D'autres 
conventions pourraient etre prises sans sortir du cadre de Pinvention. 

Le code source "JAVA" qui va etre considere ci-apres a titre 
d'exemple particulier est le suivant : 



15 Source "JAVA" (1) : 

Public void method(){ 

int[] buffer; //Declaration 

buffer=new int[2] ; // creation d'un tableau d'entiers de 2 
20 elements 

buffer[1]=5 ; // initialisation du tableau avec la valeur 5 

} 



Apres un passage dans un compilateur approprie, un fichier 
25 "classe" contenant le "p-code" (2) correspondant au code source ci-dessus 
(1) est obtenu. II se presente comme suit : 

" p-code " (2) : 



30 



iconst_2 // Push int constant 2 
newarray TJNT 
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aload 1 



astore 1 



into buffer 
intQ buffer 



i const 1 



// Push int constant 1 



i const 5 



// Push int constant 5 



5 



iastore 



return 



Comme il est bien connu de I'homme de metier, les trois premieres 
lignes correspondent a la creation du tableau precite (voir code source (1)). 

10 Les cinq dernieres lignes correspondent a ('initialisation de ce tableau 

On va maintenant illustrer en detail les etapes d'une execution 
correcte du "p-code" ci-dessus. Puisque le "p-code" est un langage de type 
interprets, les lignes successives sont lues les unes apres les autres et les 
etapes precitees correspondent a ('execution de ces lignes, avec 

15 eventuellement ('execution d'iterations et/ou de branchements. Dans ce qui 
suit, les differentes lignes de code sont graissees pour les mettre en 
evidence. 



Etape 1 : n iconst_2" 

La figure 1 A illustre de fagon schematique I'etape d'execution de ce 
"p-code". On a represents, sous la reference 1, la memoire du systeme 
embarque a puce electronique (non represents). De fagon plus precise, 

25 cette memoire 1 est divisee en quatre parties principales, deux etant 
communes a I'art connu : la zone dite "zone data" (donnees) 2a et la zone 
dite "zone variable locale" 3a. Ces zones, 2a et 3a, constituent la pile 
proprement dite de la machine virtuelle "JAVA" (JVM) que I'on appellera ci- 
apres par simplification "pile de la JVM". 

30 A ces zones sont associees des zones de memoire, 4a et 5a, 

respectivement, specifiques a Tinvention, que Ton appellera zones de 



Execution correcte : 



20 
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"Typage". Selon un des aspects de Tinvention, les zones de memoire, 4a et 
5a, sont destinees a stocker des elements d'information de type (de 
longueur 3 bits dans Texemple decrit) associes aux donnees stockees dans 
les zones 2a et 3a, respectivement, dans des emplacements de memoire en 

5 relation biunivoque avec les emplacements de memoire de ces zones. 
L'organisation logique de ces zones de memoire est du type dit "pile" comme 
rappele. Aussi, el les ont ete representees sous la forme de tableaux de 
dimensions cx/, avec c nombre de colonnes et / nombre de lignes, c'est-a- 
dire la "hauteur 0 de la pile ou niveau (qui peut varier a chaque etape de 

10 Texecution d'un "p-code"). Dans I'exemple, c=4 pour les zones "zone data" 
2a et "zone variable locale" 3a (chaque colonne correspondant a une 
position de memoire de 4 octets, soit au total 32 bits), et c=3 pour les zones 
de "typage", 4a et 5a, (chaque colonne correspondant a une position de 
memoire de 1 bit). Sur la figure 1A, le nombre de lignes represents (ou 

15 numero de niveau : 1 a 32 maximum dans I'exemple decrit) est egal a 2 
pour toutes les zones de memoire. Chacune des zones de memoire, 2a a 
5a, constitue done une pile elementaire. 

On doit bien comprendre cependant que, physiquement, les 
positions de memoires precitees peuvent etre realisees a base de divers 

20 circuits electroniques : cellules de memoire vive, registres, etc. De meme, 
elles ne sont pas forcement contigues dans Pespace memoire 1. La figure 
1 A ne constitue qu'une representation schematique de I'organisation logique 
en piles de la memoire 1 . 

U "opcode" a executer pendant cette premiere etape n J a ni 

25 parametre, ni operande. La valeur entiere 2 (soit "0002") est placee dans la 
pile : au niveau 1 (ligne inferieure dans Texemple) de la zone 2a. La zone de 
"Typage" correspondante 4a est mise a jour. 

D'apres les conventions de la TABLE I, la valeur "int" (entier) "000" 
(en bits) est placee dans la zone de "Typage" 4a, egalement au niveau 1 

30 (ligne inferieure). Aucune valeur n'est placee dans la "zone variable locale" 
3a. II en est de meme de la zone de "Typage" correspondante 5a. 
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Etape 2 : newarray TJNT 

L'etape correspondante est illustree par la figure 1 B. 

Les elements communs a la figure 1 A portent les memes references 
numeriques et ne seront re-decrits qu'en tant que de besoin. Seule la valeur 
5 litterale associee aux valeurs numeriques est modifiee. Elle est identique a 
celle de la figure correspondante, soit b dans le cas de la figure 1B, de 
maniere a caracteriser les modifications successives des contenus des 
zones de memoire. II en sera de meme pour les figures suivantes 1 C a 1 G. 

U "opcode" a executer pendant cette deuxieme etape a pour 
10 parametre le type de tableau a creer (soit type "int"). 

Cet "opcode" a pour operande une valeur qui doit etre de type "int 1 ', 
correspondant a la taille du tableau a creer (soit 2). 

La verification de la zone de "Typage" (a I'etat 4a) indique un type 
correct. L'execution est done possible. 
15 Un objet reference est cree dans la "Pile JVM" : par exemple la 

valeur (arbitraire) de quatre octets "1234" est placee dans les positions de 
memoire de la "zone variable locale" (niveau 1). Puisqu'il s'agit d'un objet de 
type reference, la valeur "100" (en bits) est placee dans la zone de "Typage" 
correspondante 5b (niveau 1). 
20 Aucune valeur n'est placee dans la zone de memoire 3b, ni dans la 

zone de "Typage" 5b. 

Etape 3 : astore_1 into buffer 

Cette etape est illustree par la figure 1C. 

U "opcode" a pour operande une valeur qui doit etre de type "Objet 
25 reference". La verification de la zone de "Typage" (a Tetat 4b) indique un 
type correct. L'execution est done possible. 

L'objet reference est deplace vers la "zone variable locale" 3c : 
emplacement 1 (niveau 1). 

Les zones de "Typage", 4c et 5c sont mise a jour : la valeur "100" 
30 (en bits) est deplacee du niveau 1 de la zone 4c vers le niveau 1 de la 
zone 5c. 
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Etape 4 : aload_1 intQ buffer 

Cette etape est illustree par la figure 1 D. 

Cet "opcode" a pour objet d'empiler I'objet reference "1234", stocke 
dans la "zone variable locale" 3d, au niveau 1 de la "zone data" 2d, c'est-a- 
5 dire dans les positions de memoire de la ligne inferieure de cette zone. 

La verification de la zone de "Typage" (a I'etat 5c) indique un type 
correct. L'execution est done possible. 

L'objet reference "1234" est place dans la "zone data" 2d. 

Les zones de "Typage" 4d et 5d sont mises a jour et stockent toutes 
10 deux, dans les emplacements de memoire correspondants, la valeur "100" 
(en bits), representative d'un type "Objet reference". 

Etape 5 : iconst_1 // Push int constant 1 

Cette etape est illustree par la figure 1 E. 

L' "opcode" a executer pendant cette etape n'a ni parametre ni 
15 operande. La valeur entiere 1 (soit "0001") est placee dans la pile : 
emplacement 2 (niveau 2) de la "zone data" 2e. La zone de "Typage" 
correspondante 4e est mise a jour, egalement au niveau 2 (le niveau 1 reste 
inchange : valeur "1000"). La valeur "int" (entier) "000" (en bits) est placee 
dans la zone de "Typage" 4 e (niveau 2). Les zones 3e et 5e restent 
20 inchangees. 

Etape 6 : iconst_5 // Push int constant 5 
Cette etape est illustree par la figure 1 F. 

L "opcode" a executer pendant cette etape n'a ni parametre ni 
operande. La valeur entiere 1 (soit "0001") est placee dans la pile : niveau 3 
25 de la "zone data" 21. La zone de "Typage" correspondante 4f est mise a jour, 
egalement au niveau 3 (les niveaux 1 et 2 restent inchanges : valeurs "1 000" 
et "000" respectivement). La valeur "int" (entier) "000" (en bits) est placee 
dans la zone de "Typage" 4f. Les zones 3f et 5f restent inchangees. 
Etape 7 : iastore 
30 Cette etape est illustree par la figure 1 G. 
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Cet "opcode" a pour operande une valeur de type 7nf", un index de 
type "int" et un objet reference de type tableau. 

La verification de la zone de "Typage" (a I'etat 4f : niveau 3) indique 
un type correct. L'execution est done possible. 
5 La valeur est stockee dans I'objet reference a I'index donne. 

Etape 7 : return 

Cet "opcode" indique la fin de la methode, la pile doit alors etre 

vide. 

En considerant de nouveau le meme "p-code" (voir (2), obtenu 
w apres compilation du code source (1)), on va maintenant detainer un 
exemple d'execution incorrecte. 



Execution incorrecte : 



15 A I'etape que Ton nommera 4' (correspondant a I'etape 4 : figure 1D). II est 
suppose que le "p-code" a ete altere et que I' "opcode" : 

"aload_1 int 0 buffer" , 
a ete remplace, par exemple, par Y "opcode" suivant : 

"iipush 0x5678", 
20 instruction dans laquelle " Ox" indique une valeur hexadecimale. 

Comme illustre par la figure 2A, cet "opcode", de type objet de 
reference, stocke au niveau 1 de la "zone variable locale" 3a', a pour objet 
d'empiler un entier de valeur "5678" dans la pile, dans la "zone data" 2'a. 

La zone de "Typage" 4a' va etre mise a jour. II s'ensuit que les 
25 niveaux 1 des zones de "Typage", 4a' et 5a 1 , vont tous deux contenir la 
valeur "100" (en bits), c*est-a-dire une valeur associee a un "Objet 
reference". Cette configuration particuliere est illustree par la figure 2A. 

L'execution se poursuit normalement comme dans le cas 
precedemment illustre par reference aux figures 1 E et 1 F. 
30 Etape 5' : iconst_1 // Push int constant 1 
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Etape 6' : iconst_5 // Push int constant 5 

Uetat des zones de la "pile de la JVM", "zone variable locale" 3b 1 et 
"zone data" 2b\ est illustre par la figure 2B. de fagon plus precise la "zone 
data" 2b 1 enregistre, au niveau 1, la valeur entiere "5678", au niveau 2, la 

5 valeur entiere "0001" et au niveau 3, la valeur entiere "0005". La "zone 
variable locale" 3a' est restee inchangee. II en est de meme de la zone de 
"Typage" correspondante 5a\ Par contre, la zone de "Typage" 4b 1 est mise a 
jour et les valeurs suivantes sont enregistrees aux niveaux respectifs 1 a 3 : 
"100", "000" et "000" (en bits). 

10 Etape 7' : iastore 

Cet "opcode" a pour operande une valeur de type "int", un index de 
type "int" et un objet reference de type tableau. 

La verification de la zone de "Typage" (niveau 1 de la zone, a Petat 
4b 1 ) indique que le code detecte est incorrect. En effet, un entier ("int" ; code 

15 "000") est attendu a la place d'un "Objet reference" (code "1 00"). 

La JVM detecte done la presence d'un "opcode" illegal menagant la 
securite du systeme. Uexecution normale de la sequence destructions en 
cours est interrompue et remplacee par ('execution destructions 
correspondant a des mesures securitaires pre-programmees : signal 

20 d'alerte, etc. 

On a suppose jusqu'a present que la largeur (ou taille) de la "pile de 
la JVM" ; que ce soit celle de la "zone data" ou la "zone variable locale", etait 
fixe, ce qui est generalement le cas dans Tart connu. Dans Texemple decrit, 
on a suppose que chaque emplacement de memoire compte quatre octets 

25 (soit 32 bits). Cependant, une telle disposition s'avere penalisante en terme 
de capacite de memoire. En effet, d'une application logicielle a Pautre, voire 
a Pinterieur d'une meme application, le nombre d'octets necessaire pour 
chaque instruction est variable. Comme il a ete indique, Pagencement les 
piles elementaires des "zone data" et "zone variable locale" telles 

30 qu'illustrees par les figures 1 A a 1G, ou 2A a 2B, ne representent qu'une vue 
logique de Pespace memoire 1. II est done tout a fait possible de conserver 
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une architecture logique du type pile, meme si les emplacements de 
memoire, successifs ou non, sont de longueurs variables, voire meme si les 
differentes positions (cellules) de memoire sont physiquement dispersees. 

Aussi, selon une premiere variante supplemental du procede 

5 selon Tinvention, les elements d'information de type permettent aussi de 
determiner la largeur instantanee necessaire, en positions de memoire, des 
zones de la "pile de la JVM". II suffit, pour ce faire, que les codes enregistres 
dans les zones de "Typage" de la memoire soient associes, en tout ou 
partie, a une information caracterisant la largeur de la pile precitee. A titre 

10 d'exemple non limitatif, il peut s'agir de bits supplemental res, ajoutes aux 
codes de typage, ou d'une combinaison de bits non utilisee de ces codes. 
Dans le premier cas, si la largeur de la pile peut varier, toujours a titre 
d'exemple, entre 1 et 4 octets, il suffit de 2 bits supplemental res pour 
caracteriser les largeurs suivantes : 

15 



Configuration binaire 


00 


01 


10 


11 


Largeur en octets 


1 


2 


3 


4 



Cette disposition, qui permet d'optimiser Tespace memoire en 
fonction des applications a executer, conduit a un gain de place de memoire 
substantiel, ce qui constitue un avantage appreciable lorsqu'il s f agit de 

20 dispositifs, telle notamment une carte a puce, dont les ressources de 
stockage sont limitees par nature. 

Selon une deuxieme variante de realisation du procede selon 
Tinvention, il est egalement possible d'utiliser les elements d'information de 
type pour indiquer si un objet est encore utilise (c f est-a-dire doit etre 

25 conserve) ou peut etre efface de la "zone variable locale". En effet, au bout 
d'un certain nombre d'operations, un objet donne enregistre dans cette zone 
n'est plus utilise. Le laisser en permanence constitue done une perte inutile 
d'espace memoire. 
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A titre d'exemple non limitatif, on peut ajouter un bit d'information 
aux codes enregistres dans les zones de "Typage", faisant fonction de 
drapeau, ou "flag" selon la terminologie anglo-saxonne. L'etat de ce bit 
indique alors si Pobjet doit etre conserve (car encore utilise) ou peut etre 
5 efface, et le marque comme tel. Les conventions arbitrages suivantes 
peuvent etre adoptes : 

- etat logique "0" = objet utilise 

- etat logique "1 " = objet pouvant etre efface 

Cette disposition, que Ton peut qualifier de mecanisme de type 
10 "garbage collector" (ou "ramasse-miettes") permet aussi un gain en espace 
memoire. 

Naturellement, les dispositions propres aux deux variantes de 
realisation supplementaires qui viennent d'etre decrites peuvent etre 
cumulees. 

15 La figure 3 illustre schematiquement un exemple d'architecture de 

systeme informatique a base duplications de carte a puce pour la miseen 
oeuvre du procede selon I'invention qui vient d'etre decrit. 

Ce systeme comprend un terminal 7, qui peut etre relie ou non a des 
reseaux exterieurs, notamment au reseau Internet f?/, par un modem ou tous 

20 moyens equivalents 71. Le terminal 7, par exemple un micro-ordinateur, 
comprend notamment un compilateur 9. Le code peut etre compile a 
Pexterieur du terminal pour donner un fichier dit " Class" (compilateur "JAVA" 
vers "Class"), c'est ce fichier qui est telecharge par un navigateur Internet, le 
micro-ordinateur comprend lui un convertisseurr qui donne un fichier dit 

25 "Cap" ("Class" vers "Cap"). Ce convertisseur reduit notamment la taille du 
fichier "Class" pour permettre de le charger sur une carte a puce. Une 
application quelconque, par exemple telechargee via le reseau Internet Rl et 
ecrite en langage "JAVA" est compilee par le compilateur 9 et chargee, via 
un lecteur de carte a puce 70 dans les circuits de memoire 1 de la carte a 

30 puce 8. Celle-ci integre, comme il a ete rappele, une machine virtuelle 
"JAVA (JVM) 6 capable d'interpreter le "p-code" issu de la compilation et 
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charges dans la memoire 1. On a egalement represents differentes piles de 
memoire : les zones "zone data" 2 et "zone variable locale' 1 3, ainsi que les 
zones de typage, 4 et 5, ces dernieres specifiques a Tinvention. La carte a 
puce 8 comprend egalement des moyens classiques de traitement de 
5 donnees relies a la memoire 1 , par exemple un microprocesseur 80. 

Les communications entre la carte a puce 8 et le terminal 7, via le 
lecteur 70, d'une part, et entre le terminal 7 et le monde exterieur, par 
exemple le reseau Internet /=?/, via le modem 71 , d'autre part, s'effectuent de 
fagon egalement classique en soi, et il n'y pas lieu de ies decrire plus avant. 
10 A la lecture de ce qui precede, on constate aisement que Tinvention 

atteint bien les buts qu'elle s'est fixes. 

Elle permet une execution securisee d'une suite destructions d'une 
application ecrite langage du type a donnees typees se deroulant dans une 
memoire a architecture de type pile. Le degre de securisation eleve est 
15 obtenu notamment du fait que la verification du code est effectuee de fagon 
dynamique, selon un des aspects de Tinvention. 

Cette disposition permet en outre, au prix d'une augmentation 
minime du temps de traitement, de se passer d'un verificateur necessitant 
des ressources de memoire importantes. Ce type de verificateur ne peut 
20 d'ailleurs convenir, dans la pratique, aux applications preferees de 
Tinvention. 

II doit etre clair cependant que Tinvention n'est pas limitee aux seuls 
exemples de realisations explicitement decrits, notamment en relation avec 
les figures 1 A a 1G, 2A a 2B et 3. 

25 De meme, bien que Tinvention s'applique plus particulierement a un 

langage de type objet, et plus particulierement au "p-code" du langage 
"JAVA", obtenu apres compilation, elle s'applique a un grand nombre de 
langage mettant en ceuvre des donnees typees, tels les langages "ADA" ou 
"KAMEL" rappeles dans le preambule de la presente description. 

30 Enfin, bien que Tinvention soit particulierement avantageuse pour 

des systemes embarques a puce electronique, dont les ressources 
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informatiques, tant de traitement de donnees que de stockage de ces 
donnees, sont limitees, notamment pour des cartes a puce, elle convient 
parfaitement, a fortiori, pour des systemes plus puissants. 



TABLE I 



Prefixe 


Type 


Code 


/ 


"Int" 


000 


s 


"Short' 


001 


b 


"Byte" 


010 


z 


"Boolean" 


011 


a 


"Object Reference" 


100 
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I3EVEINID0CATI1QMS 



1. Procede pour I'execution securisee d'une sequence d'instructions d'une 
application informatique se presentant sous la forme de donnees typees 
enregistrees dans une premiere serie d'emplacements determines d'une 
memoire d'un systeme informatique, notamment un systeme embarque a 
puce electronique, caracterise en ce que des donnees supplemental res 
dites elements d'information de type sont associees a chacune desdites 
donnees typees, de maniere a specifier le type de ces donnees, en ce 
que lesdits elements d'information de type sont enregistres dans une 
deuxieme serie d'emplacements de memoire determines (4, 5) de ladite 
memoire (1) de systeme informatique (8), et en ce que, avant I'execution 
d'instructions d'un type predetermine, il est procede a une verification en 
continu, prealable a I'execution d'instructions predeterminees, de la 
concordance entre un type indique par ces instructions et un type attendu 
indique par lesdits elements d'information de type enregistres dans ladite 
deuxieme serie d'emplacement de memoire (4, 5), de maniere n'autoriser 
ladite execution qu'en cas de concordance entre lesdits types. 

2. Procede selon la revendication 1 , caracterise en ce que chacun desdits 
elements d'information de type est constitue par une suite de bits 
enregistres dans des emplacements de memoire de ladite deuxieme serie 
(4, 5), en correspondance biunivoque avec des emplacements de 
memoire de ladite premiere serie (2, 3) dans lesquels sont enregistrees 
desdites donnees typees associees, et dont la configuration est 
representative d'un desdits types de donnees typees. 

3. Procede selon la revendication 1, caracterise en ce que lesdites 
instructions etant celles d'une application ecrite en langage "JAVA" 
(marque deposee), lesdites donnees typees sont constitutes par des 
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objets types, en ce que ledit systeme informatique integre une piece de 
logicielle dite machine virtuelle "JAVA" (5) manipulant lesdits objets types, 
en ce que, lesdits emplacements de memoire (2-5) de ladite memoire (1) 
du systeme informatique (8) etant organises en piles comportant un 

5 nombre maximum de niveaux determine, chaque niveau constituant un 
desdits emplacements de memoire, lesdits objets types sont enregistres 
dans au moins une premiere pile elementaire dite zone de donnees (2) et 
un deuxieme pile elementaire dite zone de variables locales (3), et en ce 
que lesdits elements deformation de type sont repartis dans deux piles 

10 elementaires supplemental res (4, 5) en relation biunivoque avec lesdites 
premiere (2) et deuxieme (3) piles elementaires, de maniere a specifier le 
type desdits objets associes enregistres dans lesdites zones de donnees 
(2) et de variables locales (3). 

4. Procede selon la revendication 1 , caracterise en ce que lorsque ladite 
15 concordance n'est pas realisee, ['execution de ladite sequence 
destructions est interrompue et remplacee par Texecution destructions 
correspondant a des mesures securitaires pre-programmees 

5- Procede selon la revendication 3, caracterise en ce que lesdits 
elements deformation de type sont associes a des elements 
20 deformation supplementaires determinant la taille desdits emplacements 
de memoires desdites piles (2, 3) enregistrant lesdits objets types, de 
maniere a rendre variable la taille desdites piles, en fonction desdits 
objets a manipuler. 

6. Procede selon la revendication 3, caracterise en ce que lesdits 
25 elements deformation de type sont associes a des elements 
deformation supplementaires, dits drapeaux, de maniere a marquer 
lesdits objets qui leur sont associes et a indiquer s'ils doivent etre 
conserves dans lesdites piles (2, 3) ou peuvent etre effaces. 
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7a Systeme embarque a carte a puce electronique comprenant des 
moyens de traitement informatique de donnees et des moyens de 
memoire pour ('execution securisee d'une sequence destructions d'une 
application informatique se presentant sous la forme de donnees typees 

5 enregistrees dans une premiere serie d'emplacements determines d'une 
memoire d'un systeme informatique, caracterise en ce que lesdits moyens 
de memoire (1) comprennent une deuxieme serie d'emplacements 
determines (4, 5) pour I'enregistrement de donnees supplementaires dites 
elements ^information de type, associes a chacune desdites donnees 

10 typees, de maniere a specifier le type de ces donnees, et des moyens de 
verification (6) permettant une verification en continu, prealable a 
I'execution destructions predetermines, de la concordance entre un 
type indique par ces instructions et un type indique par lesdits elements 
d'information de type, de maniere n'autoriser ladite execution qu'en cas 

15 de concordance entre lesdits types. 

So Systeme selon la revendication 7, caracterise en ce que, ladite 
premiere serie d'emplacements determines de ladite memoire (1) du 
systeme embarque a puce electronique (8) etant organisee en piles 
comportant un nombre maximum de niveaux determine, chaque niveau 

20 constituant un desdits emplacements de memoire, lesdites donnees 
typees sont enregistrees dans au moins une premiere pile elemental re 
dite zone de donnees (2) et une deuxieme pile elementaire dite zone de 
variables locales (3), et en ce que ladite deuxieme serie d'emplacements 
de memoire est aussi organisee en piles elementaires (4, 5), en relation 

25 biunivoque avec lesdites premiere (2) et deuxieme (3) piles elementaires. 

9. Systeme selon la revendication 8, caracterise en ce que lesdits 
elements d'information de type enregistres dans ladite deuxieme serie 
d'emplacements de memoire (4, 5) sont associes a des elements 
d'information supplementaires determinant la taille desdits emplacements 
30 de memoires desdites piles (2, 3) enregistrant lesdites donnees typees. 
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Systeme selon la revendication 7, caracterise en ce que ledit 
systeme embarque est une carte a puce (8). 
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Abstract 



One of the major factors that distinguishes LISP 
from many other languages (Pascal, C, Fortran, etc.) is 
the need for run-time type checking. Run-time type 
checking is implemented by adding to each data object 
a tag that encodes type information. Tags must be 
compared for type compatibility, removed when using 
the data, and inserted when new data items are created. 
This tag manipulation, together with other work related 
to dynamic type checking and generic operations, 
constitutes a significant component of the execution 
time of LISP programs. This has led both to the 
development of LISP machines that support tag 
checking in hardware and to the avoidance of type 
checking by users running on stock hardware. To 
understand the role and necessity of special-purpose 
hardware for tag handling, we first measure the cost of 
type checking operations for a group of LISP programs. 
We then examine hardware and software 
implementations of tag operations and estimate the cost 
of tag handling with the different tag implementation 
schemes. The data shows that minimal levels of 
support provide most of the benefits, and that tag 
operations can be relatively inexpensive, even when no 
special hardware support is present. 



1. Introduction 

In statically typed languages like Pascal, type 
checking is done at compile-time. Languages like LISP 
do not require the user to specify the type of each data 
item so run-time type checking is required. Run-time 
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type checking is implemented by adding a tag to each 
data item to encode the type of that item; operations on 
the data can then be type checked. On general-purpose 
processors, the tag is usually stored together with the 
data, or with a pointer to the data, in a single word. On 
LISP machines, the word length is often extended to 
accommodate tag bits, which are then handled with 
separate hardware. General-purpose machines must 
explicidy extract and compare tags when checking 
types and remove tags when operating on tagged data. 
Dynamic type checking, while chiefly concerned with 
tag operations, also involves support of generic 
arithmetic. 

An earlier study [18] on the run-time behavior of 
LISP showed that LISP programs spend an average of 
one fourth of their execution time on handling tags with 
type checking turned off. This cost was the primary 
motivation for the creation of LISP machines with a 
tagged architecture. LISP machines with tag support 
have instructions that can operate on the tag and the 
data part of an item, without having to disassemble it 
with separate instructions, and they usually support tag 
checking operations in parallel with other operations. 
For example, an integer add and the type check on the 
two operands occur simultaneously. Adding run-time 
checking to primitive LISP operations slows down our 
set of LISP programs by 25%, so overlapping some or 
all of this testing with other operations can give a 
substantial speedup. 

In this paper we first study the cost of tag handling 
for ten LISP programs that were executed on the MIPS- 
X reduced-instniction-set processor. We then describe 
a number of tag implementations, including both 
software schemes, which can be used on general- 
purpose architectures, and hardware schemes for LISP 
machines. We compare how effective they are at 
reducing the cost of tag handling; finally we discuss 
generic arithmetic in Section 4. 



2. Portable Standard Lisp on MIPS-X 

The data presented in this paper are based on 
measurements of ten Portable Standard Lisp programs 
that were executed on an instruction-level simulator for 
MIPS-X, a high-performance microprocessor [10]. 
MIPS-X is used as a typical example of a rcduced- 
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instruction-set processor. An advantage of using a 
RISC architecture in this type of study is that one can 
measure both instruction counts and execution time 
easily, since the latter depends directly on the former 
(ignoring cache misses). The programs we have 
studied include a compiler front-end, a garbage 
collector, and a rational function e valuator, and three of 
the larger Gabriel benchmarks [7]; together the ten 
programs contain about 11000 lines of LISP code, 
without comments. Details about the benchmarks 
appear in the Appendix. Portable Standard Lisp 
[8,9] is a small, efficient LISP dialect. In the 
remainder of this section we discuss the PSL 
implementation on MIPS-X. 

2.1. The Implementation of tags 

The PSL implementation on MIPS-X uses a 5 bit tag 
that is stored in the most significant part of the word; 
the remaining 27 bits contain a pointer to the data. For 
some data types, the data item contains immediate data, 
e.g. symbols and integers that fit in 27 bits. There are 
four operations related to tags: 

o tag insertion: given a piece of data, or a pointer, 
and its type (tag value), construct the data item, 

o tag removal: given an item, extract the data item, 
that is, clear the tag and create a valid pointer or 
data item, 

otaz extraction: given an item, extract the tag 
value, 

o tag checking: given an item, test the value of its 
tag; this is implemented as a tag extraction 
followed by a conditional branch. 

The tag value for positive integers is 0, and for 
negative integers, 31 (all l*s). As a result of this 
choice, the LISP representation for an integer is the 
same as its two's complement machine representation 
[9]. This means that integer arithmetic done on short 
(27-bit) integers without type checking can use the 
arilhm eticr*in stmctions of the processor without any 
need for reformatting. This optimization speeds up all 
low level integer operations. Because of the special tag 
encoding for integers, type checking for integers is 
different from other data types (see Section 4.1). 
Testing for overflow for integer additions (and 
subtractions) can be implemented as a type checking 
operation: if we add two LISP integer items and 
overflow occurs, then the result will not be a LISP 
integer. This special treatment of integers is justified 
by their high frequency of use. 

2.2. Run-time checking and generic 
operations 

How much run-time type checking is done, and how 
it -is done, strongly influence the number of tag 
checking operations that are executed. For this reason, 
we first optimized PSL run-time checking [19] to make 



its performance comparable to that of some newer, 
optimized LISP systems [3, 11]. In this section, we 
describe what data types are used in our test programs, 
and how type checking is done for those types. 

For a lot of operations, run-time checking is 
equivalent to checking the tag of the operand. An 
important example is type checking on to operations 
such as car and cdr. the operand has to be a list, 
otherwise the operation is illegal. Type, checking for a 
symbol also consists of a single tag check. Run-time 
checking for vector accesses is more complicated. 
Compilers for language like Pascal and C often allow 
the programmer to specify run-time bounds checking. 
In LISP, vector accesses with full run-time checking 
will not only do bounds checking, but will also check 
that the indexed object is a vector and that the indexing 
type is legal. 

Because the type of the operands of an arithmetic 
operation is not known at compile time, the LISP run- 
time system has to deal with type conversion and has to 
pick an operator that matches the type of the operands. 
This generic arithmetic can be implemented by doing a 
type dispatch on the type of the operands, but integers 
are by far the most common type of numbers in 
LISP [24], and generic arithmetic can be speeded up by 
first specifically testing for integer operands, thus 
giving a fast result for the most common integer case. 
The expensive general sequence is only used if non- 
integers are involved. The integer tests and the integer 
operation are done inline. 

Most LISP dialects define more data types than are 
used in our programs, but the data objects most actively 
used will be of the types we discussed (numbers, 
symbols, lists, or vectors). A lot of the other data types 
are also modeled after, or are implemented on top of 
one of the above types, for example: structures, strings, 
and bit-vectors [17], Because the data types used in our 
programs, and the implementation of tag checking are 
both similar to what is found in other modern LISP 
systems, we expect that the numbers presented in this 
paper are representative for most LISP dialects. 



3. Time spent on tag operations 

In this section we look at how much time LISP 
programs spend on various tag operations. LISP 
usually requires run-time checking on all operations, 
but there are several important cases where these 
checks are not required. First, when the compiler can 
determine the type of an operand based on the program 
context [12], or when the programmer uses variable 
declarations or type specific operators [16, 13,3], the 
type checking operations can be removed without 
affecting correctness or security. Second, many LISP 
compilers have a flag that determines whether the 
compiler will give priority to speed or to safety [17]. 
The importance of optimizing run-time type checking 
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cannot be accurately measured until we know the 
frequency of its occurrence in real programs. Because 
the amount of run-time checking depends on techniques 
to minimize the checks, we have collected data in two 
extreme situations: when no type checking is done, and 
when full run-time checking is done. A real LISP 
program will lie between these two extremes. 

Adding run-time checking to our set of programs 
increases the execution time with 25% on average, but 
the slowdown for individual programs ranges from 6% 
to 88% (Table 1). Checking on list operations is 
responsible for most of the increase in execution time, 
but for opt and trav, the contribution of checking vector 
operations is significant, and rat does a fair amount of 
arithmetic. 





arith 


vector 


list 


total 


inter 


0 


.63 


0 


.00 


19.04 


19.68 


deduce 


0 


.09 


0 


.00 


12.27 


12.36 


dedgc 


0 


.04 


0 


.00 


6.58 


6.62 


rat 


4 


.85 


0 


.00 


13.69 


18.54 


coxnp 


0 


.05 


0 


.00 


10.34 


10.39 


opt 


2 


.68 


11 


.76 


27.99 


42.43 


frl 


0 


.45 


0 


.00 


9.72 


10.17 


boyer 


0 


.00 


0 


.00 


17.50 


17.50 


brow 


0 


.03 


0 


.00 


19.91 


19.94 


trav 


3 


.09 


71 


.96 


13.19 


88.25 


average 


1 


.19 


8 


.37 


15.02 


24.59 



Table 1: Percentage increase in execution time 
when run-time checking is added 

In this paper, the 'cost' without (with) run-time 
checking, is expressed as a percentage of the execution 
time of the programs without (with) run-time checking. 
The tags are implemented as described in Section 2.1, 
but changes in the implementation, like putting the tags 
in the low order bits, should not influence our results 
significantly. 

3.1. Tag Insertion 

A tag has to be inserted each time when a new item 
is created. Inserting a tag in a data item when both the 
tag and the item are in a register costs two cycles: one 
to shift the tag to the most significant bits, and one to 
4 or* the tag and the item together. Because of our 
choice of tag values, no tag insertion is necessary when 
an integer is created. Figure 1 shows that the ten 
programs spend on average 1.5% of their time on the 
insertion of tags. 

We will not discuss tag insertion any further in this 
document, both because it is not time critical, and 
because there is little possibility for improvement by 



simple changes in software or hardware. For example, 
keeping a preshifted list tag in a register (and thus 
reducing the cost of tag insertion for list cells to one 
cycle) would speed up our programs only 0.5%. 

3.2. Tag removal 

On MIPS-X, the tag has to be removed before the 
data part of an item can be used, except for integers. 
Removing the tag can be done in one cycle by masking 
it out with a mask kept in a register. Figure 1 shows that 
the programs without run-time checking spend 8.7% of 
their time on masking out tags. With run-time 
checking, the cost drops to 7%, because the total 
execution time has increased (due to time spent on 
extracting and checking tags) while the time spent on 
tag removal stays the same. 



25 t- 



20 - 



15 - 



10 - 




cost without run-time checking 
cost added by run-time checking 
cost with run-time checking 




insertion removal extraction checking 



Figure 1: Percentage of time spent 
on all tag handling operations 



3.3. Tag extraction 

On MIPS-X, it is necessary to extract the tag of a 
data item before it can be compared with a known tag 
value to check the type of the item. Tag extraction can 
be done in a single cycle with a logical shift that places 
the tag in the low order part of the word. Figure 1 
shows that 4% of the execution time is spent on tag 
extraction when no run-time checking is done. These 
tag extraction operations are part of type tests that are 
explicidy specified in the source program. 

The dark histogram in Figure 1 shows the cost of tag 
extraction in programs with full run-time checking. 
The black part of the graph corresponds to the 
operations that were already present in the programs 
without run-time checking (light grey histogram), and 
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the dark grey corresponds to the operations that were 
added as .part, of the run-time checking; both 
components are expressed as a percentage of the 
execution time with run-time checking. Adding full 
run-time checking sharply increases the extraction cost 
and checking list operations is responsible for 80% of 
this increase. When we add run-time checking, the 
increase in the number of tag extraction operations, and 
thus in the number of tag checking operations, is about 
equal to the number of tag removal operations. This is 
what one would expect: with full run-time checking the 
type of each data item is checked before the item is 
used and using an item requires the removal of its tag. 

3.4. Tag checking 

Figure 1 shows that programs without run-time 
checking, spend 11% of their time on tag checking. 
The cost of tag checking includes die cost of extracting 
the tag, one cycle for a comparison, and possibly one or 
two cycles for unused branch delay slots. With full 
run-time checking almost 24% of the execution time is 
used for tag checking. Both with and without run-time 
testing, 95% of the tag checking operations are of the 
simple type (tag extraction followed by a comparison 
with a constant); the remaining tag checking operations 
are related to testing for integers and numbers. 

3.5. Summary 

In this section we saw that the total cost of tag 
handling is between 22% and 32% (Figure 1), 
depending on how much run-time checking is done. 
This cost is fairly constant across all programs - the 
standard deviations are 5.6% and 7.5% respectively - 
although the programs are widely different In the 
following sections we will look at different tag 
implementations that reduce the cost of tag handling: in 
^Section 4 we discuss software tag implementations that 
speed up integer testing, and in Sections 5 and 6 we 
look at schemes that can be used to reduce the cost of 
tag removal and tag checking. The hardware schemes 
proposed must be evaluated not only for improvements 
in instruction count, but also for potential negative 
impact on the processor's cycle time. 

4. Software optimization of generic 
arithmetic and integer testing 

If the tag is kept in the low order part of the word, 
integers should have tag value 0 for fast arithmetic, and 
integer testing is the same as for other data types. But 
when the tag is kept in the most significant part of the 
word, integers should get a tag that is the sign extension 
of their sign bit, and type checking for integers is more 
expensive, because positive and negative integers have 
different tags. This section first describes tag checking 



for integers, and then demonstrates how a special tag 
encoding can reduce the number of test-for-integer 
operations that are required for integer-biased generic 
arithmetic. 

4.1. Support for Integer testing 

Testing for an integer, if the tag is in the most 
significant part of the word, can be implemented in a 
number of ways (assume 5 tag bits): 

1. Extract the tag, then check for a positive integer; 
if that fails, check for a negative integer. 

2. Sign extend the least significant 28 bits; the item 
is an integer if the result is equal to the original 
item. 

3. Assuming that an arithmetic shift left gives a 
trap on overflow, doing an arithmetic shift left 
over 4 bits will trap if the item is not an integer. 

The last method allows integer testing in a single 
cycle, but unfortunately, most architectures do not have 
a true arithmetic shift left Recovering from a trap is 
also expensive, so this implementation would probably 
only be acceptable if a non-integer operand represents 
an error condition. Neither the first nor the second 
method require special hardware. It depends on the 
sign of the number which one is the fastest The second 
method was used for the measurements in this paper, 
and it always costs 3 cycles. The first method is faster 
for positive numbers, and slower for negative numbers. 

4.2. Reducing the eost of generic 
arithmetic 

With integer-biased generic arithmetic (Section 2.2) 
the cost of generic arithmetic, averaged over the ten 
programs, is only 2%, but for computation intensive 
programs, this cost can be substantially higher. In rat, 
which is the most computation intensive program in our 
set, 8% of the execution time is spent on generic 
arithmetic. In this section we describe how the 
overhead of integer testing, which dominates the cost of 
generic arithmetic for simple integer operations, can be 
reduced by using a special tag encoding. 

A generic integer add takes 10 cycles: 9 cycles for 
type and overflow checking, and 1 for adding. The 
reason for this high cost is that 3 type checking 
operations are required: two for the operands, and one 
to check die result for overflow. If we assign tag values 
in such a way that the sum of two non-integer tag 
values can never result in an integer tag value, then we 
can add the numbers, and do all the type and overflow 
checking with one single type checking operation on 
the result. This reduces the cost of a generic add of two 
integers to 4 cycles. For some other arithmetic 
operations the speedup would be smaller because more 
than one type test is necessary. With this special 
encoding of tags, the time spent on generic arithmetic 
drops to 1.6%, or a gain of 0.4% over the scheme with a 



53 



>JSDOCiD- <XD 



; • . • 

• .„ , - - ; _ 21 <1987)Oct., No. 4, Washington , DC , USA 



straightforward tag encoding; for rat, the speedup is 
about 2%. 

The requirement on tag values can be met by using 
an extra tag bit; in the case of PSL, 6 tag bits instead of 
5. With 6 tag bits it is possible to assign tag bits in such 
a way that the sum of two non-integer tag values, with 
possibly a cany in, can never result in a integer tag 
value without giving overflow. Another possibility is 
to keep 5 tag bits, and to reduce the number of tag 
values that are required by putting some typing 
information with the data. 

This tag implementation has the disadvantage that it 
requires an extra tag bit. Not only does this reduce the 
address size by one bit, but it also means that this 
scheme cannot be used with tag implementations that 
allow only 2 or 3 tag bits (see Section S3). Since these 
tag implementations have a higher payoff, at least for 
our set of programs, we will not use the encoding 
described in this section. But if enough tag bits are 
available, and if generic arithmetic is important, then 
the special tag encoding deserves consideration. 



5. Support for tag removal 

In Section 3.2 we found that our set of LISP 
programs spend around 9% of their time masking out 
the tag of a data item in order to be able to use the data 
part. In this section we first discuss the need for tag 
removal. Then we show what can be gained if tag 
removal is not necessary, and finally we describe a 
number of tag implementations that eliminate the need 
for tag removal. 

5.1. The need for tag removal 

The data pan of most LISP objects contains a pointer 
to the data, so it will always be used as an address. 
*Two important exceptions are integers and symbols. 
We saw earlier that no tag removal is necessary for 
integers, and symbols are either compared with other 
symbols, without removing the tag, or they are used as 
an index in a symbol table, in which case the data pan 
of the item is again used for the purpose of addressing a 
memory location. On a processor that drops the top 5 
bits of 32 bit addresses before accessing memory, it is 
not necessary to mask the tag of an item explicitf y when 
the data part of the item is used to access memory, 
which is, as we just argued, usually the case. 

We changed the compiler so that no masking of the 
tag is done for items that are used as addresses, and we 
changed the simulator, so that it only uses the bottom 
27 bits of an address when accessing memory. Figure 2 
shows, for programs with no run-time checking, the 
decrease in instruction frequencies resulting from this 
optimization. When we compare the 'and* entry in 
Figure 2 with the 'removal* entry in Figure 1, we see 



that almost all masking operations have been removed. 
Pan of the gain is undone by an increase in move 
instructions which is a consequence of the requirement 
that all load instructions have to be idem potent 
(repea table). -The increase in wasted cycles (no-ops and 
squashed instructions) results from the fact that fewer 
ALU instructions are available to fill delay slots after 
branches, loads and stores. Not having to mask the tag 
speeds up our programs 5.7% on average. 



10t- 




move noop squash 



totaJ 



Figure 2: Reduction in instruction frequencies 
due to the elimination of tag removal 



5.2. Implementation 

Removal of the tag when an object is used as an 
address could be accomplished in either hardware or 
software. A hardware solution is available on machines 
where the address length is shorter than the word length 
and the tag can be placed in the upper bits of the word. 
Several architectures with this property exist (68000 

[20], IBM/370 [23]), but most architectures that are 
designed today have a full 32 bit address space. LISP 
machines typically treat the tag and the data pan of a 
data item as separate entities, so it is natural that die tag 
is automatically dropped when memory is accessed 

[1. 14]. 

Given a general-purpose processor like MIPS-X it 
would be possible to add special hardware that would 
blank out the 5 most significant bits of each address, 
before it is put on the address bus. This hardware could 
be controlled by a bit in the processor status word or 
special load and store instructions could be added to the 
instruction set 

It is possible to avoid the need for tag masking by 
making only changes in the software. On MIPS-X, 
most tag removals for addresses could be eliminated by 
using the two low-order bits of a word as a tag. M3PS- 
X uses byte addresses, but all memory accesses are 
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word aligned, hence, the bottom two bits of an address 
axe dropped before the (word-addressed) memory is 
accessed. With two tag bits, three combinations are 
used to encode the most frequently used data types, 
leaving one combination as an escape, and thus 
eliminating tag masking for most memory accesses. On 
architectures that look at the two bottom bits of the 
address, this approach can still be used, but the 
compiler has to adjust the offset that is used to access 
the object so that the tag is eliminated, as is done in 
[15]. 

It is possible to avoid tag removal for more LISP 
types by using the three bottom bits for tag encoding. 
Even and odd integers get the tag values 000 and 100, 
so that integer arithmetic and indexing in word vectors 
will be fast, four tag values can be used for frequently 
used data types, and the values 011 and 111 (two 
bottom bits 1) are reserved as an escape. For data types 
with 3 bit tags, data objects will always be aligned on 
even or odd word boundaries. This is not a problem 
since list cells always require two words, and other 
types such as vectors and structures often come in 
larger blocks, so wasting a word to ensure the 
alignment is relatively cheap. Aligning list cells on 
double word boundaries might also be beneficial for 
caches with block sizes larger than two. The Lucid 
Common Lisp compiler uses the three bottom bits as 
tag bits for some architectures. 

Not having to strip the tag of an item before 
accessing memory can save almost 6% in execution 
time, and several simple implementations exist The 
software schemes that place the tag in the bottom two 
or three bits are very attractive: they avoid tag removal 
for almost all memory accesses without requiring 
special hardware, and they have the added advantage 
that the address space is not limited, which is important 
for large LISP systems. 

6. Support for 
tag extraction and tag checking 

Our programs spend between 11% and 24% of their 
time on tag checking (Figure 1), depending on how 
much run-time checking is done, so tag checking is an 
attractive candidate for optimization. Tag checking 
operations, or type dispatching, are required in a 
number of situations: 

1. run-time error checking, for example type 
checking as part of a car operation, 

2. generic operations, for example generic 
arithmetic, and 

3. checking operations specified at the source 
level, for example the function atom. 

Ignoring efforts to eliminate type and tag checking at 
compile-time using type deduction, the cost of tag 
checking can be reduced in two ways. First, by 
eliminating the need for tag extraction, thus reducing 



the cost of tag checking operations in all of the above 
categories. Second, by eliminating some tag checking 
operations completely in some of the categories. 
Because tag checking is a very simple operation, there 
is no room for software optimization, and both 
approaches require hardware changes. Both strategies 
are discussed in this section. 

6.1. Eliminating tag extraction 

We saw in Section 3.4 that tag extraction followed 
by a single eq/neq comparison is the most common 
form of type checking. The tag extraction operation 
can be avoided with a special conditional eq/neq branch 
that only tests the part of the word that contains the tag. 
This would eliminate almost 4% of the instructions, if 
no run-time checking is done, and about 10% of the 
instructions with full run-time checking. Some 
architectures, for example the VAX-11, have 
instructions that compare bit-fields directly, and that 
allow tag checking without explicit tag extraction. 
However, these instructions must be faster than a 
sequence of simpler instructions if they are to yield a 
performance improvement 

The special conditional branches can be implemented 
in a number of ways. First, it can be hardwired into the 
processor what bits will be used in the comparison. 
Hiis is not very flexible, because the architecture, and 
not the software, determines where the tag bits should 
be placed in the word, but such an implementation is 
acceptable for LISP machines [14, 6, 21]. Second, the 
special conditional branch can take a mask as a third 
argument. This solution is more flexible, but it is 
expensive to implement because it introduces an 
instruction with 3 sources, complicating the data path 
and shortening the branch offset. Third, the bits can be 
specified by a mask that is set under program control. 
This can either be implemented by having a special 
mask register, or by using a specific general purpose 
register, in which case we would still need 3 reads from 
the register file. Note that an eq/neq comparison on 
part of a word, specified by a mask, is easy to 
implement and is also very fast 

6.2. Hardware tag checking 

The cost of tag checking can be substantially reduced 
by providing special hardware that does some tag 
checking operations in parallel with other operations. It 
is not really possible to eliminate tag checking 
operations that are specified in the source code 
(category three of the beginning of this section), but 
LISP machines such as the Symbolics 3600 [14], TI 
Explorer [6] and SPUR [21] provide hardware support 
for tag checking operations that result from error 
checking on primitive operations, and from generic 
operations (categories one and two). 
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6.2.1. Error checking 

Software tag checking used for error testing on 
primitive LISP operations can be eliminated by having 
special memory instructions that check the tag of the 
address during address calculation, and that trap if the 
tag does not have the expected value; the expected tag 
could be specified in a register, as an immediate, or in 
the opcode. The hardware test is limited to a simple tag 
check; for operations such as list accessing, this is 
sufficient, but for vector operations, range checking 
would still have to be done in software. 

Hardware for parallel error checking is very simple if 
the tag location and the tag values, can be built into the 
hardware. For example, if the expected data type is 
encoded in the opcode, a PLA with the opcode and the 
operand tag as inputs, and a single output indicating 
success or failure, is all that is needed. The hardware 
becomes a lot more complicated if the tag 
implementation has to be left to the software. 

For MEPS-X specifically, two difficulties would arise 
when adding parallel tag checking. First, the path to 
load/store data from/to the cache is critical; adding 
gates to that path to implement parallel checking and 
trapping, would slow down the processor. Second, the 
MIPS-X design tries to detect the arrival of an 
exception (e.g. traps and interrupts) as early as possible, 
to keep the exception handling out of the critical path of 
the processor. Adding an instruction that could 
explicitly trap, might reduce the time that is available to 
handle exceptions, thus slowing down the processor. 

Run-time error checking on list operations accounts 
for between 0% and 12% of the execution time in our 
programs. Adding hardware to do this test in parallel 
with the address calculation would eliminate this cost, 
plus an extra 0%-4% because no tag removal would be 
required for memory accesses to lists. Extending the 
hardware to allow parallel type checking for other data 
types (vectors and structures), could give a speedup 
similar to the speedup for lists, depending on what rint? 
types are used in the program. 

Note that the MIPS-X architecture naturally allows 
some overlap between an operation and its 
corresponding tag checking operation. With a squashed 
delayed branch, two instructions are executed while the 
branch condition is calculated and while the next 
instruction is fetched, and the effect of both instructions 
is cancelled if the the branch does not go [5]. An 
operation and its lag check will happen concurrently, if 
the branch condition is 'tag equal to expected tag' and 
if the operation is moved in a delayed slot of the 
branch. 

6.2.2. Generic operations 

Generic operations are operations that can handle 
data of different types. Examples are generic arithmetic 
and the function equal. Generic operations can be 
implemented in software by testing sequentially for the 



different possible data types, by dispatching on the type 
of the operand(s) (basically a case statement), or by a 
combination of the two, as described in see Section 22 
for integer-biased generic arithmetic. It is possible to 
provides hardware support for generic operations at 
various levels. A first possibility is to test the type of 
the operands, while executing the operation, assuming 
that the operands are of the most common type. If the 
test fails, a trap is generated, and the operation is 
aborted; less common data types can then be handled in 
software. The implementation of arithmetic operations 
on SPUR [21] follows this strategy. This approach is 
very fast for the most common data type, but the 
treatment of other data types can be slow, depending on 
how fast traps are handled, and on how often the 'less 
common* case occurs. A floating point program that 
uses integer-biased generic arithmetic could well be 
slower than an integer-biased software implementation, 
because of the trap overhead. Trap handling can be 
simplified, at the expense of extra hardware, by the use 
of shadow registers that cache the operands [22]. 

By also providing hardware support for dispatching 
on the type of operands, it is possible to further speed 
up generic operations [14, 6]. The VLSI chip used in 
the TI Explorer II [2], for example, has a special on- 
chip memory for dispatch tables that can be used by the 
micro-code. Generic arithmetic operations are 
implemented by testing for the most common integer 
case while starting the integer operation, and if the test 
fails, the micro-code dispatches on the type of the 
operands. This approach is similar to the software 
implementation of generic arithmetic on general- 
purpose processors, but it will be faster, if the extra 
hardware is free, because it allows more parallelism. 

The hardware described in this section would reduce 
the cost of generic arithmetic to 1.3%, down from 2%; 
all operands are integers, so a type dispatch is never 
needed. If a type dispatch is needed, the performance 
of the different tag implementations will vary strongly. 
When a type dispatch is needed for every arithmetic 
operation, that is, the inline test always fails, then with 
the MIPS-X software tag implementation, the overhead 
of the type dispatch would increase the average 
execution time by 2.7%. We expect that this number 
will be lower on a processor like the Symbolics, but it 
will be higher if less common data types cause a trap, as 
in SPUR. 

Compile-time analysis can be used to reduce the cost 
of using the wrong bias. If compile-time analysts 
indicates that the operands are probably not integers, 
the compiler can generate code that invokes the general 
dispatch routine, or a (software) routine with a different 
bias. As the compiler is more and more successful at 
deriving data types, the 'less common' case will 
become more and more an exception. 
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7. Summary: what can hardware buy? 

Table 2 shows what fraction of the cycles (after 
pipeline scheduling) would be eliminated in the ten PSL 
programs, with the various software and hardware tag 
implementations discussed in this paper. The programs 
were executed as described in Section 3, and the 
speedup is relative to the execution time with the 
straightforward tag implementation of Section 2.1. The 
two columns give results for programs with, and 
without run-time checking, and each column gives the 
speedup relative to the execution time for that column. 
The exact speedup will depend on the quality of the 
compiler, and on whether the compiler has been tuned 
for speed or for safety. Remember that adding full 
run-time checking in software slows down our 
programs by 25% on average. 

The first three rows summarize the results for the tag 
implem^^t^siofy^ 

• row one corresponds to a software tag 
implementation in which the tag is kept in the 
bottom two or three bits of the word so no 
explicit tag removal is necessary before accessing 
memory; load and store instructions that ignore 
the tag bits m the address give the same speedup. 

• row two gives the speedup if the processor has a 
special conditional branch that checks the tae 
without extracting it B 

• row three gives the result if the implementations 
of rows one and two are combined 

These three implementations require either no hardware 
changes, or very simple hardware changes. 



The fourth row shows the reduction in cycles if we 
had special hardware that traps if an arithmetic 
operation has non-integer operands, or if overflow 
occurs. The speedup is small because our programs are 
not computation intensive; note that the tag 
implementation of Section 4.2 would further reduce the 
gain of hardware support for generic arithmetic over a 
software implementation, but that tag implementation is 
not compatible with the implementation of row 1. The 
fifth row gives the speedup if tag checking on list 
operations is done with extra hardware in parallel with 
the address calculation (Section 6.2). In the sixth row 
we assumed that parallel tag checking is not only 
possible for lists, but also for vectors and structures. 
These hardware additions are more substantial because 
they influence the control of MIPS -X. 

The seventh row corresponds to a processor that has' 

1. loads and stores that ignore the tag (row 1) 

2. ^ia;*ir^uta8rfe* To check the' tag without 
extracting it (row 2), B wiuiuul 

3. hardware for generic arithmetic (row 4), 

4. loads and stores that do parallel error checking 
for all data types (row 6). 8 

This is to the maximum amount of hardware support 

that can be added to MIPS-X without requiring a total 

reorganization of the processor, it would eliminate 

between 9% and 22% of the cycles. This savings 

should be compared with the software implementation 

of row one (6%-5%), and with row three (9%-14%) 

which only requires very limited hardware changes 



no run -time 
checking 



run-time 
checking 



-1- 


avoid tag masking (software) 


5.7% 


4.6% 


-2- 


avoid tag extraction 




3.6% 


9.3% 


-3- 


avoid masking and extraction 


9.3% 


13.9% 


-4- 


support generic arithmetic 




0% 


0.7% 


-5- 


avoid tag checking 
on list ops 


check 

mask 

total 


0% 
0% 
0% 


12.1% 
4.2% 
16.3% 


-6- 


avoid error 
tag cheeking 
(lists+vectors) 


check 

mask 

total 


0% 
0% 
0% 


13.6% 
4.6% 
18.2% 


-7- 


avoid masking 

avoid extraction 

avoid all error tag checking 

total 


5.7% 
3.6% 
0.0% 
9.3% 


4.6% 
2.9% 
14.6% 
22.1% 



Speedup in percent for different degrees of hardware support 



57 



NSDOCID <XP «709A I > 



Operating Systems Review 
21 -(1987)Oct., No. 4, Washington, DC, USA 



More complex hardware support, such as microcode 
support for type dispatching, is possible. However, it 
would require a total reorganization of the MIPS-X 
architecture, and our results indicate that the payoff 
would be much less than the negative impact of the 
added hardware on cycle time and other performance 
measures. 

SPUR [21] provides hardware support for tag 
handling corresponding to row seven, except that SPUR 
does not allow parallel checking on memory accesses 
other than list accesses (row 5 instead of row 6). As a 
result, the SPUR tag hardware would eliminate between 
9% and 21% of the cycles in our programs, although 
the gain drops to between 4% and 16% of the cycles, if 
the software tag implementation of row one is used on 
MIPS-X. 



8. Conclusion 

In this paper we first looked at the cost of the various 
tag handling operations, if a straightforward tag 
implementation is used. We found thai tag checking, 
which includes the cost of extracting the tag, is the most 
expensive operation, certainly if full checking at run- 
time is required (ll%-24% of execution time). Tag 
removal, which is done before using the data, uses 
about 8% of the execution time, and tag insertion uses 
1.5%. 

Then, we looked at how the cost of tag handling can 
be reduced with different software and hardware tag 
implementations. The cost of tag removal can be 
reduced in software by putting the tag in the bottom 2 
or 3 bits of the data word; this results in a speedup of 
about 5%. Speeding up tag checking requires special 
hardware. One possibility is to eliminate the need for 
tag extraction before a tag check. This is easy to 
implement, and it gives a speedup of 4% to 9%, 
depending on how many tag checking operations can be 
eliminated by the compiler. The two optimizations 
combined eliminate between 9% and 14% of the cycles. 
Another possibility is to have special hardware that 
does tag checking in parallel with memory access 
operations. This, together with the previous features, 
gives a speedup of between 9% and 22%, but it requires 
more complicated hardware, and the tag 
implementation has to be built into the architecture. 



Appendix 

The following set of 10 LISP programs were used to 
collect data: 

• inter, a simple interpreter for a subset of LISP is 
used to calculate the Fibbonachi number 10, and 
to sort a list of numbers; adapted from "Lisp in 
Lisp" [25]. 

• deduce: a deductive information retriever for a 



database organized as a discrimination tree; 
adapted from [4]. 

• dedgc: the same program as deduce* but a 
copying garbage collector is invoked. The 
progra m spends about 50% of its time in the 
garbage collector. 

• tot. a rational function evaluator that comes with 
the PSL system. 

• comp: the first pass of the front-end of the PSL 
compiler. 

• opr. the optimizer that was added to the compiler. 
It uses lists, and vectors. 

• frl: a simple inventory system using the frame 
representation language. 

• boyen the boyer benchmark; a rewrite-rule-based 
simplifier combined with a dumb tautology- 
checker; benchmark published by Gabriel [7]. 

• brow, a short version of the browse benchmark; 
creates and browses through an Al-like database 
of units; benchmark published by Gabriel [7]. 

• trav: a short version of the traverse benchmark; 
creates and traverses a tree structure; uses 
structures which are implemented as vectors; 
benchmark published by Gabriel [7]. 

Table 3 gives the number of procedures, the number 
of lines of source code (without comments), and the 
number of MIPS-X machine instructions after 
compilation, for each program. Each program includes 
besides the user program, the LISP system modules, or 
parts of modules, that are used by the program. 





number 


lines 


words 




of 


source 


objed 




procedures 


code 


code 


inter 


64 


710 


1533 


deduce 


100 


900 


3419 


dedgc 


116 


1100 


4112 


rat 


148 


1900 


6315 


coop 


220 


2400 


9466 


opt 


226 


3500 


11121 


frl 


198 


2500 


11802 


boyer 


84 


1200 


1793 


brow 


91 


1000 


2296 


trav 


78 


810 


1673 



Table 3: Information on the 10 test programs 
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ABSTRACT 

An algorithm for efficient concurrent garbage 
collection is presented and analyzed. The 
algorithm is based on the concept of tagged memory 
where each element is combined with an associative 
tag to denote its property. The associative tag is 
used to indicate whether the corresponding element 
is free for allocation, marked as an active node, 
and queued for marking. The garbage collection 
(GC) process marks a queued node and queues the 
unmarked successors, whereas the list manipulation 
(LM) process queues the candidate nodes for 
marking using the tag and the primitive operations 
on it. The correctness of the algorithm is proved. 
It is claimed that according to the proposed 
algorithm (1) no free list is necessary for memory 
allocation. (2) fast marking is achieved without a 
stack or the critical section, and (3) the LM and 
GC processes would experience fewer memory access 
conflicts. List compacting is not considered here. 



In the classical reclamation scheme £13), 
the GC process is activated only after the 
depletion of free available nodes. It starts with 
the marking of all accessible nodes. The nodes 
left unmarked at the end of the marking phase 
are regarded as garbage nodes. These nodes are 
then appended to the free list which is a 
linear list of free available nodes. Upon 
completion of reclamation, the LM process is 
resumed. Although implementation of the 

classical scheme is stra ighf orward , the major 
disadvantages include degraded performance and 
unpredictable response time. The latter problem 
in particular can be resolved by using 
interleaved collection method in which the LM and 
GC processes time-share the processor, as 
described by Bobrow [3] and Knuth [8, p. 422, 
P. 594). This method called incremental garbage 
collection guarantees continuous run of a user 
program. However. the incremental collection 

scheme causes greater delay in list processing 
than the classical scheme [21]. 



I. INTRODUCTION 

Lists are the fundamental data struc- 
ture in many areas of computation, especially 
in artificia l intelli gence programs. Good 
facilities for manipulating lists are essential to 
the machines for such computation. From the list 
management point of view, list processing can 
be functionally dichotomized into list 
manipulation and garbage collection. A list 
manipulation process. (LM process) is responsible 
for creating and maintaining lists. Since 
the list processing usually relies on the dynamic 
^ e fr?°J*.y allocation, list nodes should be ayaiTable 
for allocation at run- time. Meanwhile, the used 
nodes are deallocated implicitly without the 
knowledge of the LM process or operating system. 
These deallocated but unidentified list nodes 
(called garbage nodes) need to be reclaimed for 
recycling under the constraint of limited 
storage space. Thus a garbage collection 
process (GC process ) i s respons i bi e for 
identifying and collecting these nodes. 



Concurrent garbage collection resolves 
these two problems: inefficiency and 

unpredictability of response time. The LM process 
and the GC process are run on separate processors 
while sharing a common list memory. Various 
concurrent algorithms have been proposed based on 
the mark-and-col iect method of McCarthy [13]. In 
general, there are two basic approaches to 
this problem: coloring method using two tag bits 
[4, 5, 11], and the stacking method [7, 10. 14. 
20, 21], The former requires no critical 

sections, thus offering conflict-free memory 
access to both processes. However, the time 
necessary for marking is 0(N) to O(iNA) where N is 
the total number of nodes in the list memory and 
A is the number of active nodes accessible to 
the LM process. Recently, similar but less 
efficient algorithm is proposed, requiring a 
single tag bit (2]. The latter stacking 

technique offers efficient marking requiring 0(A) 
time, but it demanas extra memory space for the 
stack which must be declared as the critical 
sect i on. 
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'Edified versions [9, 15] have been 
. r. :i .-.->scd to achieve efficient marking in O(A) 
however, they have failed to eliminate the 
--,-11 for significant extra memory space for 
..!•*: nc. This is considered a serious drawback 
■ r.vjse shortage in memory is the very reason 
:::«it the garbage collection is needed 
••.Hvoyer. the possible saving of space accrued 
taster marking (as observed in (21 J ) may 
..ffset by the requirement of extra space for 
-i r.%: rig. 

In this paper, an efficient algorithm 
:-.r concurrent garbage collection is developed 
■•.s-'d on the mark-and~col lect method Using 
.^.nstvely a two-bit associative tag which 
m.v addressed by its contents, they combine the 
.; ,!nnns . method and the stacking method 

• -o. in general, the algorithm accomplishes 
: " r;or : ance . improvements for the memory 

.^cation; in particular, efficient marking in 
A. time with no critical section or 

\!Z * T C % re « uired ' economical 
•cement of free available nodes. List 

• -^acting is not considered . here because a 
.:^;i ?e collection scheme with the marking and 

•►I action phases is perfectly satisfactory. 

in what follows, definitions and assumptions 
• • ftven in the next section. Sections 3 and 4 
; scribe the respective procedures necessary for 
W Process and the.GC process. Section 5 is 
i-rov.ded with the proof of correctness of 
>!>e concurrent algorithm. Section 6 shows the 

oct of the algorithm on system performance 
inclusions are drawn in Section 7. 



'I- DEFINITIONS AND ASSUNfPTIONS 
List Representation 

but » M ?J f truct ^e is in essence nothing 
™L collection of list nodes in which each 
node usually contains two pointers to 
!f; ode , 5 - ™ ere are two types of list nodes: 
Pointer node and data node. A pointer node is a 
number of contiguous words which consists of 
tno pointers, LLINK and RLLNK. A data node 

nodI ain ff ?v V3lUe; S °' 11 is always a terminal 
noae. If there are no list nodes to point to 

W J^?^ ° r RLLXK) has lvalue NIL 

-oof ^ tHe header node of a list called the 
joot no de is accessible to every node in that 

The list nodes are linearly labeled in the 
''St memory. Each node has an associative tag 
a ?? the m *mory allocation point of view a node 
a|ls lnt o one of the following classes: 

(a) Active nodes: the nodes which are accessi- 
ble from at least one of the root nodes. 

Cb) ~ree nodes : the nodes which are availa- 
ble for ai locat ion. 



(c) Garbage nodes : the nodes which are in- 
accessible from any roots and are not 
available for allocation. 

t« ^ff ma ?° r 8 °?J ° f garbage collection is 
to determine the accessibility G f nodes and 
distinguish between active nodes and garbage 

k I equires th « traversal of t 

graph which is discussed in the next sect on 
Dynamic memory allocation in list ornH« 
changes the node type at run-time as Lew" 



>| free node j- 



allo- 



ca t i on 



">l active node | — 



garbage node |<- 



garbage 
col lect ion 
2.2 State of List Nodes 



deal lo- 



cat ion 



At any instant of time/ a node is in * 

^ a, it S ir e and^h ° f ! a ^ 

garbage " . chan ^ es as > ist manipulation and 

consists of the fol lowing s'ta te^Car i ab^s" 

(a) Fvar: indicates whether a node is free 
available) for allocation. If available 
then Fvar=l: else Fvar=0. 

as a [hJ^i- ateS : het ^ Gr a node is " a ^ 

Mvar-f- 1V V° de A If marked ' the " 
Mvar=l . else Mvar=0. 

(O Qvar: indicates whether a node is queued 
for marking ,„ the foreseeable future 
If queued, then Qvar=l : else Qvar-0 

Slatejvame State Vector Description 



Fstate 
Mstate 
Qstate 

Gstate 



(1,0,0) 
(0,1,0) 
(0,0,1) 



(0,0.0) 



free node 

active node, marked 
active node, 
queued for marking 
garbage node 



2. 3 Assoc iat ive Tag 
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Boolean variable "empty.- The following 

operations are defined on the tag. Separated by a 
vertical bar, the first set of arguments of each 
operaton represents input parameters: the 
second set represents the output parameters. 

(a) Read(addri state) : Read and return the 
content state at location addr. 

(b) WriteC addr.statel ) : Replace the 
content with state at location addr. 

(c) Find( state j addr. empty) : Search for any 

one of the nodes which are in state, 
and return its address addr with empty 
set to false. If the search fails, 
return empty set to true. 

The associative tag, especially the Find 
operation, can be effectively implemented using 
the Boolean content addresable memory [17]. 



indefinitely. appropriate actions are taken by 
the operating system to avoid the infinite loop. 

3.2 Redirecting of Pointers 

Identification of garbage nodes is achieved 
by marking all active nodes. In order to 
cooperate with the GC process for correct 
identification of garbage nodes, the LM process 
should ensure that when a pointer is modified 
the node pointed to by the new pointer may be 
marked as an active node. The redirecting of 
pointers is defined as having an existing 
pointer directed to another active node. 

To do so, whenever a pointer is redirected 
-to point to an active node n^ , n fl must be queued 

for marking if it has not been marked. A 
procedure for the pointer alteration must 
include the provisions shown in Fig. lb. 



2.4 Assumptions 

(1) The minimum time require for the 
creation of a list element is greater 
than the maximum interval between two 
consecutive instances of marking a node. 

(2) The primitive operations are atomic*, 
so execution of each operation is 
un i nterruptabl e. 

(3) A set of root nodes for all lists is 
provided for the GC process; so all the 
active nodes are accessible to the root 
nodes . 

(4) The content of data nodes is NIL. 



III. LIST MANIPULATION PROCESS 

3.1 Allocation of Free Nodes 

The LM process carries out two important 
functions in relation to concurrent garbage 
collection: allocation of free nodes and 
cooperation with the GC process in identifying 
garbage nodes. A linear list called free list 
has been used conventionally for the allocation of 
free nodes so that all free nodes may be traced. 
Alternatively. a bit-map or bit-table may be 
used where a bit is reserved for each list node 
to indicate whether it is free or active [6]. Our 
approach makes use of the associative tag so that 
free nodes have their tag set to Fstate. 

When a free node is requested for the 
creation of a list element, the memory is searched 
for a node which is in Fstate. Once found, its 
state is changed to Qstate to ensure that the 
node will be marked as an active node by the GC 
process. So when a new list element is created, 
the address of a free node is provided according 
to the procedure shown in Fig. la. It is assumed 
that when the "empty" variable is false 



PROCEDURE FreeNodeAddress(addr) ; 
BEGIN 
REPEAT 

Find (Fstate j addr, empty ) 
UNTIL empty = False: 
Wri te( addr, Qstate j ) 
END 

(a) Procedure PI: Allocation of free nodes 



PROCEDURE Queuelt(newpointer) ; 

(* "newpointer" is a redirected pointer *) 
BEGIN " ' 

Read(newpo inter jstate) ; 
IF state = Gstate THEN 

Wri te(newpo inter, Qstate | ) 
EXD 

(b) Procedure P2: An auxiliary to pointer 
al terat ion 

Figure 1 1 Procedures PI and P2 for the LM process 



IV. GARBAGE COLLECTION PROCESS 

4.1 Pseude-Random Search 

Pseudo-random search (PRS) forms the 
foundation of marking algorithm for concurrent 
garbage collection. Using an undirected graph 
whose vertices have three possible states, 
namely, Gstate, Mstate and Qstate. we now 
summarize the PRS a I gor i thm proposed in [17}. 

The search begins with setting the state of 
all vertices to Gstate. Next the start vertex- 
is put in Qstate. Then as a vertex in Qstate is 
selected and visited, its adjacent vertices in 
Gstate are ail placed" in Qstate. This cycle 
repeats until no more vertex in Qstate is left. 
The algorithm is given below. 
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*. rEDURE Pseud oRandomSearcM start vert ex) 

yyt each vertex DO set its state to Gstate; 
?-jt the state of startvertex to Qstate; 
V.UILE there is a vertex v in Qstate DO 
BEGIN 

Set the state of v to Mstate; 

FOR each vertex w adjacent to v DO 

Set state of w to Qstate if in Gstate; 

:v 

:.i Garbage Collection Algorithm 

Vne GC process consists of two phases: 
.irking and transformation. In the marking 
::ise, all active nodes are marked so unmarked 
. ;?s are identified as garbage nodes. The 
•.iking process follows the PRS: given the 
:<-*u node of each list structure, the GC process 
reverses the structure using the PRS technique, 
the transformation phase, garbage nodes are 
: r:::-s formed into free nodes. So all the nodes 
• :i Uie list memory that have not been marked in 
: ! <. rrarking phase are incorporated into the 
:.v»» available space. The garbage collection 
:it>cedure P3 is shown in Fig. 2. 

The GC process begins by initializing all 
. ;;;t nodes except free nodes to Gstate. In 
ir.\' marking phase, each rooted list structure is 
: . 4 *->roughly traversed as observed in the PRS. The 
v.- live nodes shared by two or more lists are 

rked once since the nodes in Qstate or Mstate 
■i:*e not allowed to be placed in Qstate 
:, .^a in. The marking is irreversible in the 

•••.■:)se that once a node is marked it can not be 
"-:::r.arked" until the next garbage collection 
•von though the node thereafter becomes 

rbage. 



Next in the transformation phase, all 
the nodes in Gstate are assigned Fstate. This 
indicates that a node is not free if it has been 
r.nrked (Mstate) or queued for marking (Qstate). 
The latter case is to prevent the node just 
allocated after the marking phase from being 
transformed into free node. In summary, all the 
garbage nodes present at the beginning of a 
garbage collection are transformed into free node 
^fter the end of it. 

V. CORRECTNESS OF THE ALGORITHM 

Correct garbage collection algorithms 
preserve the integrity of list structures 
throughout the GC process. The LM process and 
the GC process should cooperate in such a way 
that 

~ The list structure should not be 

modified as a result of garbage collection. 

~ The garbage collection terminates properly 
so that the garbage nodes are transformed 
into free node after predictable amount of 
t i me . 



PROCEDURE GarbageCol lect ion (root); 
BrCIN (^Initial izat ion*) 

FOR i :=1 to N DO 
BEEIN 

Read(i {state): 
IF state O Fstate THEN 
WriteU.Cstatel ) 

END: 

<*MARK I NG PHASE*) 
FOR i:=l to M DO (*M = number of roots*) 
BEGIN 
node : = root [ i ] ; 
REPEAT 
Wr i te(node,Mstate| ) : 
FOR each link DO 
BEGIN 

succesor :« SUCC( node . 1 i nk ) ; 
IF succesor O xNIL THEN 
BEGIN 

Read (successor (state) : 
IF state - Gstate THEN 
Wr i te( successor .Qstate | ) 

END 

END: 

Fi nd (Qstate | node , empty) 
UNTIL empty = True 
END: 

(* TRANSFORMATION PHASE*) 
FOR i :=1 to N DO 
BEGIN 

Read(i |state): 
IF state = Gstate THEN 
Write(i , Fstate! ) 

END 

END 

(*The function SUCC returns the address of the 
successor node specified by the parameters.*) 

Figure 2 : Procedure P3 for the GC process 

- No active nodes should be mistaken for 
garbage nodes. 



In the 
i nvest igated 
and P3. 



following, these requirements are 
according to the procedures PI. P2 



5.1 Proper Manipulation of List Structures 

The list structures are manipulated by the 

LM process as a garbage collection proceeds. So 

the GC process should not interfere with the LM 
process in manipulating the lists. 

Theorem 1 r No list structures are modified 
as a result of the garbage collection. 

Proof: The list structure is mutated when a 
node or a pointer is added or removed. The 
parallel procedures Pi through P3 do not involve 
any operations on the pointer or value in a 
node except for the function SUCC in P3. 
This function, however, only fetches a pointer in 
a given node. and does not alter its content. 
Hence no nodes or pointers are modified by the 
a 1 gor i thm.D 
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5.2 Proper Termination 

Only the marking phase is considered for the 
proper termination of the GC process because the 
time required for the transformation is O(N) 
according to procedure P3. Let 



T = 



R = 



the minimum interval between the two 
consecutive instances of allocating a 
new node, 

the maximum interval between two con- 
secutive instances of marking a node, 
T m /T a < 1 by the assumption given in 

Section 2, 

the number of active nodes at the be- 
ginning of the marking phase. 



Lemma 2 : The time required for the marking 
phase is less than or equal to T N 0 (1-R) n 
R) if the active nodes are marked once, where n = 



U-logN 0 /logRJ. 



Proof : All active nodes that are marked by 
the GC process have been either active or newly 
allocated since the beginning of the marking 
phase. The total number, N t , of active nodes can 
be calculated for the worst 
active nodes are always 
existing active nodes 
marking proceeds. In 
N. act i ve nodes are 

Secome 



case where new- 
created and no 
are deallocated while the 
other words, every time 
marked t. /T nodes 



active anew, 
time required to mark 



I 



t. stands for the maxi 



N. 



nodes. 



Note that 



because T >T 



mum 

N. 
i 



The following shows 



how the marking progresses in time. 



N. 



t. =N T 
1 1 m 



N 2 =t l 
*2 = N 2 T m 



N a =1 



properly 



Theorem 3 : The garbage collection terminates 

: r 1 y . 



Proof ■ The time required 



for 



the 



initialization and the transformation in the 
procedure ?3 is clearly 0(N). According to Lemma 
2 the garbage collection terminates within the 
finite period of time if active nodes are 
marked once. Nodes are marked if they are in 
Qstate except for the root nodes. The 
procedures PI through P3 indicate that Qstate is 
assigned only when the nodes have never been 
marked or queued. As a result each node is 
queued for marking once, thus marked once.D 



5.3 No Mistaken Active Nodes 

If there were any active nodes mistaken for 
garbage, these active nodes must have not been 
marked during the marking phase. In order to 
prove that all the active nodes are marked, it is 
necessary to show that (1) initially all the 
active nodes except the root nodes are queued for 
marking, and that (2) once queued, they are all 
marked. Note that all the root nodes are marked 
according to the procedure P3. 

These tasks can be accomplished by the proper 
cooperation between the LM process and the GC 
process. The cooperation centers around the 
operations on the associative tag. The 
correctness of their cooperation can be proved 
by showing that the tag is properly manipulated. 
State transition occurs when a write operation is 
performed on the tag of individual nodes. 
For correct identification of garbage nodes, the 
state of each node must undergo the transition 
intended by a given process only. If there 
are any possibilities of undesirable state 
transition, the correctness of the algorithm is 
not guaranteed. The state transitions in the 

algorithm can be summarized as follows: 



"here in general >L - /T and t, =N, T 

k K 1 a kkm 

Hence the total number of active nodes for marki 

is the sum of a geometric series. 



ng 



- N l * N 2 



+ N 



= X 



N n T /T 
0 m a 



+ N n £T /T ) 



n-1 



- N 0 (1-R) n /(1-R) 



where the integer n must be the largest 
integer that satisfies the relationship N Q R n_1 > 1. 
Thus the total time necessary for the 
marking phase in the worst case is T N - T N 
- t _o \ n / / , r^, m t m * 0 

K ' /H-R) where n = LL-log.\ ? 0 /logRJ. □ 



PI 
P2 
P3 



Fstate — > Qstate 
Gstate — > Qstate 

Qstate — > Gstate > Mstate 

1 I 
Mstate— | I— > Qstate — > Mstate 



I— > Fstate 
process does 



with L f£T a t L 0116 process does ^t interfere 
with the other process with respect tc 



transi t ion. 



to the state 



th, FF 21 ' 311 consider the LM Process vs 

the GC process. that is, PI and P2 vs P3 By 
nspection the state transitions in Pi an d P3 are 
round mutually exclusive. The transition 

ronf[ 3 ^ ° f P2 a £ ?3 ' howev er, show possible 
2 1m ^ P2 ,/ ries to cha "ee Gstate to 
M*iM' r m f y . atU ^ fc to change Gstate to 

Mstate or Fstate. The transition of Gstate -> 

If PO ^ S ?u CUrS ° n,y t0 r00t nodes regardless 
of P2. On the other hand. the transition of 
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■ ; s tate -> Fstate in P3 occurs in the 
: rans format ion phase, when all the active nodes 
:-ive been either marked or queued. Because no 
Vilte transition is allowed for such nodes 
.^■cording to P2, there are no possibilities 
„f interference. Consequently, the 

:::tegrity of the state transitions in the two 
• : .-cesses are preserved. □ 



Tab \ e 1 . A Performance Comparison for Parallel 
Garbage Collection Algorithms 



Theorem 5 : All the active 
:>>ued for marking correctly. 



nodes 



Proof : When every node is marked all of its 
-;:ccessors are queued according to the procedure 
I*:;. Every active node that is created after the 
i.t-ji inning of the marking phase is also queued 
•ivcording to PI. The only case that an active 
...tie is not queued is when its sole predecessor 
.tilt unmarked) is replaced by another 
-accessor (already marked). However. this 
problem is resolved in P2 where a new 
v.uccssor resulting from the redirecting of a 
>>:nter is -queued for marking explicitly. 
Wording to Lemma 4, this is performed correct ly.D 

Theorem 6 : While in the marking phase. all 
r.ctive nodes in Qstate are marked. 

Proof: During the marking and 

i rans format ion phases the transition diagram 
..f P3 shows that the only possible state 
transitions are from Qstate to Mstate. These 
transitions occur correctly according to Lemma 4. 
il.nce. all the queued nodes are marked during the 
r-arking phase. Q 



VI. PERFORMANCE IMPROVEMENTS 

The concurrent garbage collection 

proposed in the preceding sections bears the 
following major advantages. A comparison of 
the proposed algorithm and other algorithms is 
given in Table 1. 



A. No free list is necessary. 



No free list need 
memory allocation. The a 
be obtained using proce 
operation find(state;a 
first free node in memory 
priority scheme. free 
sequentially from lower 
lo higher ( or 1 ower ) 
accrue from it. First, 
maintain the structure 
ft usually involves the. d 
f^ce nodes. and the 
Pointers. Second, i 

implemented as a simpl 
node must be declared the 
the LM and the CC 
Properly. This sen 

synchronization measure, 
references to the point 
°y the GC process resu 
conflicts as discussed be 



s to be maintained for 
ddress of a free node can 
dure PI. Assuming the 
ddr. empty) locates the 
with an appropriate 
nodes are allocated 
(or higher) address 
address. Several gains 
the time required to 
of a free list is saved, 
eletion and appending of 
subsequent updating of 
f the free list is 
e linear list, its header 
critical section so that 
processes may cooperate 
erne obviates such 
Last, less frequent 
er part of the memory 
Its in less memory access 
1 ow. 



Marking algorithms Stacking 



Col or i ng Assoc . 

lag 



Time 
Extra bits/node 
Extra space 
Critical section 
Free list 



0(A) 
1 

stack 
stack 



0(N)-0(N*A) 
2 

none 
none 



0(A) 
2 



necessary necessary 



B. No stack is necessary for efficient marking. 

A stack is required for the efficient marking 
algorithms with 0(A) computation time where A 
is the number of active nodes. In this case, only 
the active nodes are marked [1, 19]. The stack 
requires extra space as large as the memory 
size in the worst case. For this reason, a great 
deal of effort has been invested in reducing the 
stack size or obviating the stack itself at the 
expense of more computation time [10, 12, 16, 22]. 
As shown in Section 3, the tagged memory 
achieves the same efficiency as obtained from 
marking with a stack. Consequently, the proposed 
marking algorithm requires little extra cost 
in terms of time and space provided the 
associative tag is given. 

C. No critical sections are necessary. 

In contrast with marking algorithms 
with a stack [6. 19, 20) and memory allocation 
with a free list, the proposed algorithm has 
no critical sect ions. ■ According I y , the two concur- 
rent processes do not require any synchronization 
schemes. Elimination of overhead in synchroniza- 
tion contributes to the speedup of computation, 
especially, in the LM process. 

D. Memory access conflicts are kept low. 

The tagged memory is logically divided 
into two parts: tag and vaule. They can also be 
implemented as physically separate regions. 
The LM process mainly works with pointers 
and data whereas the GC process utilizes the tag 
except for the addresses of successor nodes at 
the time of marking. Hence the possibility of 
the access conflict is considered substantially 
low. ~ 



VII. CONCLUSION 

The proposed algorithms for concurrent 
garbage collection makes use of a two-bit 
associative tag. First, in this algoritlim. the 
free list need not be maintained for memory 
allocation. Second, the marking based on the new 
graph traversal algorithm can be efficiently 
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conducted without the need for a stack and the 
critical section. Third, the list processor and 
the garbage collector would experience fewer 
memory access conflicts because of absence of 
the critical section and possible separation of 
the pointer region from the tag region. 
Last, the implementation is straightforward if 
the CAM and the dual port memory are provided. 

This parallel algorithm is suitable for 
real-time applications where the predictable, 
short response time is crucial. It may be 
extended to the case of the concurrent garbage 
col lect ion wi th multiple list processors. In 
this case, the procedure PI needs to be modified 
so the free nodes are allocated properly. It may 
also be extended to parallel garbage collection 
where multiple garbage collectors run 
simultaneously [18]. 
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Abstract. The use of smart cards to run software modules on demand 
has become a major business concern for application issuers. Such down- 
loadable executable content needs to be trusted by the card execution 
environment in order to ensure that an instruction on a memory area 
is compliant with the definition of the data stored in this area (i.e. its 
type). Current solutions for smart cards rely on three techniques. For 
Java Card, either an off-card verifier- converter performs a static verifica- 
tion of type-safety, or a defensive virtual machine performs the verifica- 
tion at runtime. For other types of open smart cards, no type- checking 
is carried out and the trust is only based on the containment of appli- 
cations. Static verification is more efficient and flexible than dynamic 
techniques. Nevertheless, as the Java verifier cannot fit into a card, the 
trust is dependent on an external third-party. In this way, the card se- 
curity has been partly turned to the outside. We propose and describe 
the FACADE language for which the type-safety verification can be per- 
formed statically on-card. 



1 Introduction 

In this section the specific domain of smart cards is described. For people not 
aware of smart cards, we briefly review the technology and the history of smart 
cards from embedded devices dedicated to specific applications up to open plat- 
forms for enabling the downloading of new services all during the card's life. 

1.1 The Specific Domain of Smart Cards 

Smart cards form a specific domain by three ways we detail hereafter: their 
interna] constitution, their interfaces, and their applications. 

A smart card is a piece of plastic, the size of a credit card, in which a single 
chip microcontroller is embedded. Usually, microcontrollers for cards contain 
a microprocessor (8-bit ones are the most widespread, but 16-bit and 32-bit 
processors can now be included in the chip) and different kinds of memories: 
RAM (for run-time data), ROM (in which the operating system and the basic 
applications are stored), and EEPROM (in which the persistent data are stored). 
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Since there are strong size constraints on the chip, the amounts of memory are 
small. Most smart cards sold today have at most 512 bytes of RAM, 32 KB of 
ROM, and 16 KB of EEPROM. This chip usually also contains some sensors (like 
light sensors, heat sensors, voltage sensors, etc.), which are used to deactivate 
the card when it is somehow physically attacked. 

In order to be usable, a smart card must be inserted in a card reader/writer, 
which provides power to the card, as well as a clock signal. Also, any communi- 
cation between the terminal and the card goes through the card reader/writer 
in the form of messages exchanged from the terminal to the card (commands), 
and respectively, from the card to the terminal (responses). All these basic as- 
pects are strongly standardized, since cards are meant to be usable with a wide 
range of devices. The family of ISO 7816 standards are the references [3]. They 
standardize many features, from the positions of the contacts on the card to 
the transport protocol that is used to communicate between the card and the 
terminal. 

A smart card can be viewed as a "data safe" , since it stores data in a secure 
manner and it is used securely during short transactions. Its hardware is the base 
fbTits^^ ifensoWIn plastic 

and glue, and that all components are on the same chip makes a physical attack 
quite difficult. The software is the second barrier for its safety. The chip programs 
are usually designed for neither returning nor modifying sensitive information 
prior to be sure that the operation is authorized. In fact, most card applications 
use the card either to safely store data, or to process sensitive data. Most smart 
cards include some support for cryptographic functions, which allows them to 
secure their transactions with the outside world. More practically, cards are often 
used either to manage some kind of currency (money or tokens) or to identify a 
person. 



1.2 Smart Cards State-of-the-Art 

The specific domain of smart cards is close to the domain of embedded devices. 
Like embedded devices, smart cards are aimed toward the consumer electronics 
market, which requires from these systems even more and more convenience and 
flexibility. 

The methods, languages and tools for developing a smart card system share 
some characteristics with those of the embedded domain. Until recently, smart 
card codes were written in hand coded native assembler. All programs (drivers, 
operating system, libraries, applications) were developed in a monolithic piece of 
code burned in the ROM of the smart card. Therefore, not only traditional card 
systems are difficult to develop (low-level programming language, very reduced- 
feature microcontroller, specific code for every microprocessor) but also they 
cannot support evolution of their applications since all the application code is 
burned forever with the runtime engine in the ROM. 

Moreover, the production of such a "petrified" monolithic program dedicated 
to a specific hardware and with ad hoc functions for the application domain con- 
sumes most of the card development cycle. In order to issue a card application, 
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what is needed is (i) to write precise specifications, (ii) to write or re-write the 
basic software (akin to an operating system) for possibly multiple platforms, 
(iii) to develop specific functions for the application, and (iv) to verify this 
software before to deploy it on thousands or millions of cards. This process is 
time-consuming and costly. Since defining specifications for products that will 
be available long afterwards is risky, this process is a difficulty for the creation 
of new markets. As it requires a long time it also severely limits the ability of 
a card issuer to deploy rapidly new applications in accordance with the market 
needs. 

In order to cope with these market needs (to simplify, a reduced "time-to- 
market" and flexibility for card applications) new generations of smart cards 
(called open smart cards) have emerged during the last two years. Most notable 
efforts towards such smart card systems are Java Card [12, 13], Mult OS [5], and 
Smart Card for Windows [6] which provide application developers an opportunity 
to create applications on a common base of code. They contain a platform for the 
dynamic (i.e. on demand) storage and the execution of downloaded executable 
content, which is based on a virtual machine for portability across multiple smart 
card microcontrollers and for security reasons. 

While these new smart cards bring solutions regarding the market needs, 
they also introduce new problems for smart card makers. They provide solu- 
tions for card application developers by enabling them to program in high-level 
languages, on a common base of software (an abstract machine and application 
programming interfaces) which isolates their code from specific hardware. In that 
sense, they can reduce drastically the time to get new applications to market. 
They also tend to support both the flexibility and the evolution of applications 
by enabling the downloading of executable content in already deployed smart 
cards. This later characteristic requires more sophistication in term of security 
techniques since any program could potentially damage or misappropriate the 
whole card system. This paper deals with this issue as summarized in the next 
section. 

1.3 Outline of this Paper 

Ensuring that a program cannot damage a system consists in denying it access to 
other memory areas than those reserved for its execution and data (containment 
or "sandboxing"). Containment relies on access controls to memory areas. It 
would be better to associate containment with a protection mechanism that also 
verifies that every instruction accesses data with respect to their types. In fact, 
a more fine-grained protection consists in verifying that every instruction that 
accesses to a memory area is compliant with the definition of the data stored 
in this area (i.e. its type, or its class in an object-oriented system). This later 
technique has been popularized in the Java language [4j. 

In the field of open smart cards, this security issue is generally addressed 
by the use of three techniques. Current solutions for smart cards rely on three 
techniques. For Java Card, either an off-card verifier-converter performs astatic 
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verification of type-safety, or a defensive virtual machine performs the verifica- 
tion at runtime. For other types of open smart cards, no type-checking is carried 
out and the trust is only based on the containment of applications. For tradi- 
tional smart cards (with all the code burned in their ROM), these techniques 
are not used because the confidence in the programs is based on the fact that 
they have been tested and verified before the delivery of the cards. 

In this paper, we propose a new architecture to build smart card code that 
is based on a typed intermediate language called FACADE. It aims at providing 
a coherent system for card software engineering enabling both, the production 
of efficient traditional smart cards, and the building of type-safe downloadable 
content for open smart cards. 

Section 2 debates the security schemes used in open smart cards before detail- 
ing the FACADE architecture. In Section 3 we focus on the verification process 
and on the precise static semantics of FACADE. A formal model using the B 
language exhibits the type-safety properties to be checked. Finally, Section 4 
summarizes the paper and gives our forthcoming future work. 

2 FACADE Architecture 
2.1 Language Related Work 

The current open smart cards provide programmers with the ability to download 
programs dynamically. This characteristic aims at making smart card systems 
more convenient in two ways. On the one band, they support the use of high- 
level languages (like Java with Java card, or Visual Basic with Smart Card for 
Windows) in spite of smart card constraints. On the other hand, they guarantee 
that the programs loaded in a smart card are not able to compromise the security 
of the other programs. 

Smart Card Compilation and Loading Process Though current smart 
cards are able to run programs written in high-level languages, they still have 
drastic limitations. Generally, the compilation of programs expressed in high- 
level languages produces a code unsuited to the available hardware. Two solu- 
tions have been used in the existing products. 

The first solution consists in defining programming languages dedicated to 
smart cards. These languages tend to be close to those used on workstations but, 
they force programmers to take into account some specific aspects of smart card 
microcontrollers. For example, the language MEL has been specifically defined 
to program the MultOS card operating system [5]. For convenience, a domain 
specific compiler can generate MEL code from C. 

Another solution consists in converting the code produced by a traditional 
compiler into a specific code adapted to the smart card constraints. For example, 
the Java class file format is too heavy to be loaded in Java Card. Thus, the class 
files produced by compilers will be treated by a specific converter in order to 
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get a compressed version of class files [14]. Smart Card for Windows is another 
example of the same technique. 

Figure 1 presents the process of compilation and loading associated with 
these two approaches. 



Fig. 1. Java Card and MultQS compilation processes 
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Code Downloading and Smart Card Security Currently, the Java Card 
framework does not support Java-like dynamic class loading. The main problem 
is that a smart card environment is too small for running the Java class file 
verifier. Open card architectures hence propose a downloading framework with 
reduced flexibility, in which the download unit is the application (or package in 
Java) rather than a single class file. In addition, new frameworks for program 
distribution and downloading have been proposed. The two major proposals are 
outlined in Figure 2. 



The first solution is known as defensive virtual machine. All safety checks are 
performed at run-time, hence replacing the pro-active static bytecode verification 
by a defensive run-time bytecode verification. For instance, before performing 
a write operation to a given memory area, the virtual machine checks the type 
and access rights associated with the data located in that target area. In Java 
Card, the checks are mostly related to typing; in MultOS, the checks are related 
to access right checks, since security is based on application containment. 

Defensive virtual machines have two major drawbacks. First, the number of 
run-time checks to be performed severely hinders their performance; then, some 
additional data (such as typing information) needs to be stored, which increases 
the memory requirements. As a consequence, this technique can only be applied 
to small programs, and this drastically reduces its flexibility and usefulness. 
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Fig»2» Two solutions for open smart cards 
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Solution 2: External Authority Signature 



The second solution consists in performing the security checks outside the 
smart card. Before to download a program onto a smart card, it is first transmit- 
ted to a trusted third-party (usually the card issuer), which checks the program 
and certifies it. When the program is downloaded, it is accompanied with its 
certificate. Before to allow this program to run, the smart card checks the valid- 
ity of the certificate. This solution is currently the one that is proposed by the 
major card issuers. However, it has a severe drawback: the whole security of the 
smart card system relies on the security of the certification scheme. This solution 
is satisfactory for local deployments, but it can be unsatisfactory for long-term 
deployment of large scale applications. In fact, a central point of trust (the cer- 
tification authority) creates a single point of failure that can compromise all the 
security architecture in case of attack. Also, in some cases, this centralization 
is not well suited to application needs in which the various participants are not 
able to trust a same authority. Moreover, the implementation and deployment 
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of a certification infrastructure is difficult and requires costly operations like 
monitoring and maintenance. For these reasons, we argue that it would be far 
preferable to design a solution in which the security of the smart card system 
relies on the smart card system rather than on a certification scheme. 

Another Approach: FACADE A recent research work [10] proposes to adapt 
the Proof Carrying Code [8] technique as a mean for verifying on-card the type- 
safety of Java Card programs. This technique seems very promising, but the com- 
plexity of the on-card processing for a full type-checking makes it still difficult 
to implement on current smart cards. We propose to solve this problem by intro- 
ducing a typed intermediate language called FACADE in which the type-safety 
can be verified on-card. As, this language is intended to be a target platform for 
multiple high-level languages such as Java or Visual Basic, it also solves some 
interoperability problems between new open smart card systems. The FACADE 
language is also a part of a framework for producing card programs. Inside this 
framework, it has two main properties: (1) it is designed specifically for an im- 
plementation on reduced feature devices, and (2) it is designed to enable an 
efficient static checking. 

2.2 The FACADE System 

The FACADE language is targeted toward very small platforms, but it is not 
specifically targeted toward open smart cards. The advantage of using such an 
intermediate language is that it can be used for all kinds of smart cards and small 
devices. The language is secure enough to be downloaded into an open smart 
card, but it can also be used to produce optimized native code, to be included in 
the ROM of a smart card. The main application of such an idea would be to use 
an high-end open smart card to prototype an application, and then to produce 
an optimized dedicated code in order to obtain smaller (and cheaper) cards for 
mass production. 

In our system, the FACADE typed intermediate language is a central ele- 
ment, as shown in Figure 3. Programs written in various source languages are 
first fed into a language-specific off-card front-end which does lexical analysis, 
parsing, type-checking, and compilation into specific representations. Then, it is 
translated into the FACADE intermediate format. The off-card middle end does 
conventional optimizations. It also generates the elements that will be necessary 
to prove the type-safety of the program when it will be loaded into the smart 
card. At this step, the FACADE code may be used in two different directions: 

1. The on-card back end for open smart cards verifies the type-safety of the pro- 
gram at loading time, and generates a dedicated code for the target hardware 
or software machine. 

2. The off-card back end for ad hoc smart cards used the FACADE code as the 
source code for producing a complete card code dedicated to be burned in 
ROM thanks to the usage of a ROMizer 1 

1 A ROMizer is a software used to produce ROM binary images of programs. 
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All the production tools are deliberately made independent of each other so that 
they may support different source languages and different target platforms. This 
paper only deals with the proof generator and verifier tools. Other components 
of this architecture are currently investigated by ongoing experimental research 
works. 



Fig. 3. FACADE architecture 
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Using a common intermediate language to share compiler infrastructure is 
not a new idea. Many compilers have used or use a common intermediate format 
for multiple source languages (e.g., GNU gec, Eiffel, Pascal, etc.). For a long 
time, Eiffel has used the C language as its intermediate language. For more 
advanced systems, specific languages have been defined. For instance, the FLINT 
architecture [11] is based on a typed intermediate format that supports higher- 
order functions and an advanced polymorphic type system. However, none of 
these languages is appropriate for small platforms such as smart cards: 

The main characteristic of FACADE is its ability to prove the type-safety 
of FACADE code using small hardware like a smart card. This feature is very 
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important in order to use the language as a target for the compilation of the 
Java language, whose security relies heavily on type-checking. Here, instead of 
trying to fit a standard Java type-checker on a smart card (as done in [9]), we 
have chosen to design a language which caters to the very specific needs of smart 
cards. In the following sections, we focus on the way in which type-checking can 
be performed on the FACADE language on a smart card. 

2.3 Principle of Type-Checking: Type Inference 

Program checks are usually based on data flow analysis. This analysis aims at 
determining the type of the variables at each program point (pp). The type of 
some variables changes during the execution of the processing because they are 
temporarily used for different computations. 

The Hierarchy of Types In the FACADE architecture, all information are 
associated with types. FACADE is an object-oriented intermediate language. 
Thus, types are commonly defined by classes. The hierarchy of classes is an 
extensible data structure. Indeed, when new applications are loaded, they add 
their own classes to those already recorded in the card system. These extensions 
are done in a tree-based model. Each class has one and only one super class. 
Moreover, one particular class: CardObject is the top of the hierarchy. Thus, 
directly or indirectly, any class extends CardObject, which is the root of the 
inheritance graph. 

For the data flow analysis, we define a semi-lattice as a tuple L = (V t C,H) 
where V is the set of the class types, C is a partial order defined over V y and H 
is a binary operation defined over V. Two elements i, j € V are incomparable, 
if neither i C j nor j C i. We say that if i, j € V, j covers i if i C j and there is 
no k such that i C k C j. In the diagram of an ordered set (V, C), two elements 
i t j £ V are directly connected if one covers the other. The Figure 4 presents the 
ordered set of FACADE types. The greatest element CardObject of V is called 
the top element of V and can be written T. 



Type-Safe Operations A program is made of a sequence of elementary op- 
erations. Each one uses some number of input data and modifies some number 
of output data. In FACADE, there are only five distinct elementary operations. 
Following, for each of them we informally provide (i) their operational semantics, 
and (ii) their static semantics. 

L. Return VarRes 

(i) This operation ends the execution of the processing and returns the value 
of the variable VarRes. 

(ii) This operation is legitimate if the type of the returned variable (VarRes) 
is a subtype or equals of/to the return type declared in the method signature. 
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Fig. 4. Ordered set of FACADE types 
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2. Jump Label Id 

(i) This operation is an unconditional jump to another operation of the 
program marked with the label labelld defined in a label table. 

(ii) This operation is defined only if the label labelld exists and the value of 
the associated pp is valid. 

3. Jumpif Var Labelld 

(i) This operation is a conditional jump. The Var variable is of type Bool 
which determines if the jump must take place or if it must be ignored. 

(ii) If the label labelld exists and the variable Var is of type Bool y this 
operation is correct. 

4. Jumplist Var nbcase {LabeUdl, Labelld2 . . .} 

(i) This conditional jump reaches the label whose sequence number, in the 
list of the labels, is equal to the variable Var, If the variable Var is negative 
or if Var is a number greater than the cardinal of the label list (defined by 
the immediate value nbcase) , the operation does not perform any jump but 
increments the program point. 

(ii) If each label Labelld x exists, if the number of labels is less or equal 
than nbcase, and if the variable Var is of type Ini, then the operation can 
be carried out. 

5. Invoke Var Res Var method! d {tabVarl,tabVar2 . . .} 

(i) This operation executes the method meihodld on the variable Var, with 
the parameters tabVarl, tabVar2 . . . Var Res is the variable that contains 
the value returned by the method call. In fact, this operation of the interme- 
diate language FACADE could be translated in the card, according to the 
nature of the method meihodld, either like a jump into another procedure, 
or like a set of elementary operations of the target machine. 

(ii) The call of a method is type-safe if first (a) the method meihodld is 
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declared in the class (the type) of Var, and second (b) the types of the 
variables tabVarl,tabVar2 . . . are included in those awaited by the method 
method) d of the class of Var y and finally (c) the type of the variable VarRes 
is that turned over by the method methodld. 

An elementary FACADE operation is considered type-safe if the inferred 
types are conform with those defined by the static semantics. For instance, let 
i and j be respectively of types Int and IntArray; an incorrect operation can 
be Invoice j,i,add, j. However, the addition method of the Int class takes an 
integer value as the second parameter. As Int Array is not a subtype of Int, such 
operation is illegal. In this other example, let i a variable of the type Short, the 
following operation is correct: Jumpl is t i, 4, (11, 12, 13, 14) , because the 
type Short is a subtype of Int. 

In fact, the variable type checks may appear to be simple if the type of a 
variable do not change during the life span of the method. Unfortunately, it is 
not the case for all kinds of variables. We distinguish two kinds of variables, 
those which have an invariable type {e.g., the attributes of an object), and those 
which have a variable type (e.g, the variables used for temporary storage during 
the evaluation of complex expressions). In the first case we speak about Local 
and in the second, we use the term Tmp. 

Type-Safe Verifier and Smart Card Constraints A type verifier proves 
that each instruction contained in a program will be executed with values having 
the types expected by the instruction. The type verifier reads the program and 
notes for each elementary operation, the produced types and the consumed types. 

Generally the execution of a program is not sequential. This is why a tradi- 
tional verifier follows the arborescent path of each case of the program execution. 
The computation of this tree structure establishes with certainty the types of the 
variables consumed and modified by the elementary operations. When various 
paths end in a same program point, the safe-type verifier determines a single 
type for each Tmp variable. 

The fixpoint search is the most complex aspect of the type-checking algo- 
rithm. As shown previously, it requires the production of a complex data struc- 
ture, and thus the execution of a complex recursive processing. The smart card 
cannot perform this recursive processing, because of its hardware limitations. 
Therefore, no smart card proposes an operating system performing at load time 
type-safety checks. And if the type-safety checks are performed at runtime, they 
slow the virtual machine. 

A Two-Step Solution Some studies propose to distribute the type-checking 
of a downloadable code between a code-producer and a code-receiver. The most 
outstanding works in this field are Proof Carrying Code [8] (PCC) and Typed 
Assembly Language [7] (TAL). The main idea of these works is to generate by 
the code-producer a proof of the program safety. The code is transmitted with 
this proof to the receiver. The code-receiver checks the program using the proof. 
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The interest of this technique is that the proof verification is much easier than 
the proof production [10]. 

In our case , the proof is the result of the type combination for a given label. 
Like TAX, we propose to provide, with the transmitted program, a list of labels 
with a state of the Trap variables for each of them i.e. for each program point 
which can be reached by a jump. The receiver performs a sequential analysis 
of the code. When an operation is marked by a label, the receiver checks if its 
current inferred types are lower or equal (relation C of the types hierarchy) to 
those defined by the proof. Moreover, when the receiver checks a kind of jump, 
it makes sure that its inferred types are lower or equal to those defined for the 
label. A program is refused if a control fails. 

3 Type-Safety Verification 

In the FACADE approach, the verification process is split in two parts. The 
resource consuming algorithm (i.e. the label generator) is done on the terminal 

^^J^^^^^^j:) while the verification oflthe 1^ 

between two labels is done on the card side (code-receiver). The first algorithm 
is a traditional type reconstruction and verification of all the possible execution 
paths. For each label (i.e. each point that can be reached by a jump operation), 
the joint operation is computed for the untyped local variables. The label table 
is transmitted to the card with the FACADE code. At loading time, the card 
sequentially computes the inference and compares it with the label table. In case 
of divergence the card refuses the code. 

The verification process must ensure that every execution will be safe. It 
means that starting in a safe state each operation will lead the system in another 
safe state. For that purpose, a transition system describing a set of constraints is 
constructed. It defines a correct state for each operation (preconditions) and how 
the system state evolves (post-conditions). Preconditions and post-conditions 
define the static semantics of FACADE. In particular, it must be ensured that: 

• all instructions have their arguments with the right type before execution, 

• all instructions transform correctly the local variables for the next pp. 

3.1 Static Semantics of FACADE 

The system maintains some tables: the class descriptors (classDsc) and the 
method descriptors (methodDsc). The class descriptors table contains the def- 
initions of the classes present in the card and the class hierarchy. The method 
descriptors table contains for every class the signatures of the already checked 
methods. Once a method has been accepted by the verifier, it is added in the 
method descriptors. 

We briefly introduce our notation. Programs are treated as partial maps 
from addresses to instructions. If Pgm is a map, Dom(Pgm) is the domain 
of Pgm. Vpp e Dorn(Pgm), Pgm pp is the value of Pgm at program point pp y 




488 



which is written Pgm[pp -4ti]. A program P is a map from program points to 
instructions. The model of our system is represented by a tuple: < pp.Tmp > 
where pp denotes a program point (or program counter), and Trnp the set of 
untyped local variables. The types of the typed local variables noted L are never 
changed, and therefore are not part of the program state. The vector of map 
T contains static information about the local variables. The vector T assigns 
types for the Trnp variables at program point pp such that Vi, (Tmp[i] : T pp [i}). 
A program is well typed if there exist T that satisfies: TV- P. 

A program is correct if the initial conditions are satisfied and if every in- 
struction in the program is well typed according to their static constraints: 

Dorn{T 1 ) = {) 
Vi€ Dom(P) i (T 9 ih P) 
Th P 

Following Figure 5 we give a formal definition for the control flow instruc- 
tions (Return, Jump, Jumplf , and JumpList) and for the invocation instruction 
(Invoke). There are two static semantics for the Invoke instruction depending 
on the kind of variable used for VarRes. 



3.2 OfF-Card Label Generation 

During this phase, we can construct the type information for local variables for 
each program point using a traditional type inference algorithm (for example, 
the Dwyer's algorithm [2]) and then, we calculate for every label the value of 
T for every path. An inference point (ip) is a pair made of a program point 
associated with the T type table for that program point (written T ex tern)- They 
are collected in a table - the label Dsc table - which is sent to the smart card. 
When a new method has been loaded, it is verified that the label descriptors 
only reference valid addresses: Vi, (i 6 label Dsc[pp] x i £ Dom(P)). Finally, we 
can formally define the label descriptors by: 

ip € labelDsc.ip = (pp,T cxicrr ,) 
pp e Dom{P) 

T ex tem ~ Tpp 

Consider the following example (see Table 1), this piece of FACADE code 
(we call it program P) uses two variables i and v in order to compute a loop 
from 0 to 100. 

Using a fixpoint algorithm, the inference procedure checks all the paths of 
the tree. In this example, it needs eight steps as illustrated Table 2. 

At step 1, i and v are Trnp variables for which the types are unknown before 
the operation. The type of the return variable for the method likelt from the 
class Int is Int. Thus, at step 2, i is assigned the type Int. At step 4, a first 
choice is made by jumping at pp 3, the other choice is verified at step 8. At 
step 6, the state is different than the step 3 (for the same pp) thus, we have not 
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Fig. 5. Static semantics of FACADE control flow and invocation instructions 
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Table 1. A sample FACADE program 



pp Label Instruction Comment 

1 Invoke i, 0, likelt i is set to 0 

2 Jump labelO go to the test at LabelO 

3 Label 1 Invoke i, i, add, 1 increment i 

4 LabelO Invoke v, i, LtOrEq, 100 test if i less or equal than 100 

5 Jumplf v, labell if TRUE go to Label 1 

6 Return void otherwise, return 



Table 2. Off- card type inference procedure of the sample FACADE program 



Step 


PP 


Label 


Instruction 


I T[i,v) 


1 


1 




Invoke i, 0, likelt 


(T,T) 


2 


2 




Jump LabelO 


(/nt. T) 


3 


4 


LabelO 


Invoke v f i, LtOrEq, 100 


T) 


4 


5 




Juapif v, labell 


(Int, Bool) 


5 


3 


Labell 


Invoke i, i, add, 1 


(Int, Bool) 


6 


4 


LabelO 


Invoke v f i, LtOrEq, 100 


(Int, Bool) 


7 


5 




Jumplf v, labell 


(Int 9 Bool) 


8 


6 




Return void 


(Int. Bool) 



reached a fixpoint. At step 7, states are identical, meaning that a fixpoint has 
been reached. Now, the pending path memorized at step 4 can be checked. 

For the 3, we have to make the combination between the two states 
T4[i,v] = (Int, Bool) (at step 6) and T 4 '[i,v] = (Int, T) (at step 3). Using our 
semi-lattice, the greatest lower bound of T 4 [i,v] and T A '[i,v] is T extern [i,v) = 
(Int, T). Our labelDsc is made of two ip: (4, [Int, T]) and (3, [Int, Bool]). 

In order to optimize the size of the data sent to the smart card, the labelDsc 
table can be reduced. In fact, by verifying the definition-use paths, one can 
remark that the information on the variable v at step 6 is useless because v is 
always defined before any use. Thus > it is possible to simplify the labelDsc as 
shown Table 3. 

Table 3. Simplification of the label descriptors table (labelDsc) 





pp 


T c3 . tcr n[i, V] 


0 


4 


(/nr,T) 


1 


3 


(Int, T) 
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3.3 On-Card Type Inference and Verification 

The on-card FACADE verifier uses the off-card-generated label descriptors in 
order to reduce its footprint in memory as well as the time needed by this 
process. After receiving the application and its labelDsc, the verifier checks the 
conformity of the label descriptors. Then, it begins the verification process by 
running sequentially through the code. 

The procedure is the following (see Table 4): for each instruction the verifier 
checks if the program point is referenced into the label descriptor. In such a 
case, the table T est ern replaces T c otherwise, the algorithm uses T c . It applies 
the static semantics to verify the correctness of the code. After an unconditional 
Jump, the following instruction must have necessarily a label, and then it replaces 
T c by T C x tern - 



Table 4. On-card verification procedure of the sample FACADE program 



Step 


PP 


Instruction 




T c [i,v) 


1 


1 


Invoke i, 0, likelt 




(T,T) 


2 


2 


Jump label 0 




(Int, T) 


3 


3 


Invoke i , i, add, 1 


(/nt.T) 


(/nfc, T) 


4 


4 


Invoke v, i, LtOrEq, 100 


(Jnt, T) 


{Jnt, T) 


5 


5 


Jmnplf v, labell 




(Jnt, Bool) 


6 


6 


Return void 




(Znt, Bool) 



At step 2, before the Jump, T c has been inferred as [Int> T], At step 3, the 
program pointer is included in the label descriptors thus, T c is overloaded by 
the external table T exte rn- At step 4, the transfer function associated with the 
method LtOrEq applied on an Int changes the type of the return parameter 
to a Bool. At step 5, the precondition to a Jumplf is to have a Bool value as 
parameter, which is satisfied. 

3,4 Status 

The complexity of the verification process is 0{ri) since the algorithm verifies se- 
quentially the instructions. Furthermore, the memory usage is reduced because 
the algorithm only needs the variables types of the current pp. If the type in- 
formation and the applet have been modified, the verifier always refuses the 
code. 

In our architecture, the card security relies mainly on the verification process. 
Therefore, the design of the type-checker cannot suffer any error. In a recent 
paper [1], we specified a formal model of a Java Card bytecode verifier and 
we provided the proof of its correct implementation. As the Java Card and the 
FACADE data flow verification are closed, we expect to achieve the formal proof 
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of the FACADE verifier in a near future. This work is part of a Ph.D. program, 
and the results will be presented in a future paper. 

4 Conclusions and Future Works 

The FACADE project is an academic research effort supported by the Gemplus 
Research Lab. It investigates the issue of software production in the field of 
smart cards. We have introduced the specific domain of smart cards. We have 
reviewed the programming techniques used for the production of traditional 
cards and open smart cards. Then, we have presented the FACADE framework 
for producing smart cards programs. 

This framework is based on a typed intermediate language dedicated to smart 
cards. The first advantage of this single intermediate format is that it enables 
migration paths between open and traditional cards, from a variety of source 
languages towards a variety of smart card runtime environments and hardware 
platforms. There are also other advantages in using a typed intermediate lan- 
guage. First, a rigorous type system can be used to verify the safety of a program. 
Second, it is possible to abstract the programmers from a single source language 
if programs of different surface languages share the same runtime system based 
on a uniform type system. Finally, type safe languages have been shown to 
support fully optimizing code generation and can efficiently implement security 
extensions (access control lists or capabilities). 

This paper focused on the type-safety verification process. We have shown 
that it is split in two parts. The off-card part is resource consuming but it 
generates important information (the labels) in order to minimize the second 
part of the verification process. By this mean, the on-card part is able to perform 
the verification with the reduced features of a smart card. For the moment, we 
are working on the complete B model of the verifier. The expected result is a 
proof of the correctness of the verification process. 

Future works are experimental researches on the execution environment of 
FACADE programs. They include the generation of target code from the FA- 
CADE language and the implementation of the runtime system libraries. This 
work will give us metrics on code size and efficiency, but also an implementation 
of the operational semantics. In order to prove also the correctness of the exe- 
cution process, we intend to develop a formal model of the dynamic semantics. 
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Over the last several months Computational Logic, Inc. (CLI) in collaboration with Schlumberger Electronic 
Transactions and JavaSoft (see "Where is JavaSoft going with its model" in the original Javasoft announcement) has 
been building a formal model of a subset of the Java Virtual Machine (JVM). The model has been built using ACL2, a 
mathematical logic based on Common Lisp. The result can serve as the basis for rigorous, formal analysis of the 
JVM and JVM (bytecode) programs. Because models written in ACL2 can be executed, the formal JVM model can 
run programs within the subset of the JVM supported. 

The model is called the "defensive" JVM (or dJVM) because it includes sufficient run-time checks to assure type-safe 
execution (or at least to detect and prevent any unsafe execution). In the standard JVM these checks are not 
present; type safety is dependent an unstated property of the bytecode verifier and the JVM. 

The first phase of the CLI effort has been to build an initial model of a significant portion of the Java Card subset of 
the JVM. This includes object creation, field access, and method invocation. This phase has been completed, and 
CLI and its collaborators are making the "alpha" release of the initial model publicly available for external review and 
comment. This snapshot demonstrates one approach to formalizing and clarifying the JVM specification. 



Availability 

The draft formal description of the model is available. Please mail any comments to Richard Cohen. 



• HTML version. 

• The full report can be downloaded as a postscript or pdf file. Each is approximately 2MB. 

NOTE: The HTML version was generated mechanically from LaTeX sources generated mechanically from the ACL2 source files. 
While this has produced a readable hyper-linked rendition, there are a number of minor formatting glitches. For the authoritative 
documentation see the report. 



The model is available as gzipped or compressed TAR files which include an executable image and the dJVM 0.5 
User's Guide in PostScript and PDF formats: 



• Gzipped for Solaris 2.5 on SPARC architecture. (31 megabytes) 

• Compressed for Solaris 2.5 on SPARC architecture.(38 megabytes) 

• Gzipped for Solaris 2.5 on x86 architecture. (26 megabytes) 

• Compressed for Solaris 2.5 on x86 architecture. (37 megabytes) 



WARNING: The current executable images are very large; they are approximately 70MB each when 
expanded. The gzipped versions are about 30 MB. The image includes the executable dJVM model as 
well as the complete ACL2 theorem prover, compiler, and all of the definitions and theorems of the dJVM 
model. 

* 

The User's Guide briefly explains how to run the model and is available as a postscript or pdf file. The ACL2 source 
files comprising the model are also available as a gzipped tar file (300KB) . 

Java, Java Card and Solaris are trademarks of Sun Microsystems, Inc. SPARC is a trademark of SPARC International, Inc. 
This page is URL http-JAvww. cti.com/software/djvm/index.htmi 
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Preface 



The Defensive Java Virtual Machine (dJVM) is a defensive version of the Java Virtual Machine 
(JVM). The dJVM augments the JVM with additional run-time checks to assure type-safe 
execution. 

We define a formal model of the dJVM using the ACL2 language. Because ACL2 is an 
executable mathematical logic, we obtain a model which we can run, as well as one about 
which we can formally reason. This provides both the clarity and proof cababilities of a 
formal, logical model, and the ability to validate the specification against our intensions by 
running test cases on the model. 

The JVM is an optimized version of the dJVM, which behaves correctly (i.e., as the 
dJVM) under proper conditions. The Java bytecode verifier is intended to assure those 
conditions by rejecting bytecode programs that do not satisfy the assumptions underlying 
the JVM optimizations. The main portion of these assumptions address the type safety of 
the bytecode program. 



Warning to the Reader 

This is a draft (or "alpha" release) of the dJVM 0.5 specification. It is meant as an explo- 
ration of formalizing the Java Virtual Machine, the the completeness of the current JVM 
documentation, and type-safe execution of the JVM. As such, the emphasis was to build 
an initial formal model of the core, object-oriented portion of the JVM. The model is called 
dJVM version 0.5 to suggest that it is only an initial step toward formally modeling the full 
Java Virtual Machine. The text that accompanies portions of the formal model is (yet) not a 
full or adequate explanation or justification of the model. 

The text is sprinkled with "author's remarks." These notes are indicative that this is an 
incomplete report of an incomplete model. The remarks are marked in the text as: 



Some of the remarks concern questions about the model or the JVM. Some are reminders Author's 
of portions of the report or the model that have to be written or revised. Note 
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Chapter 1 



Introduction 



The Java Virtual Machine QVM) is a key part underlying the definition and portability of 
Java programs. The JVM is a relatively clean and simple abstract machine, which has been 
realized in software (as an interpreter) and is being realized in hardware as well. The JVM 
has a bytecoded instruction set designed to be compact and easily interpreted in either 
hardware or software. 

The JVM is an object-oriented machine, manipulating objects as well as numeric data. 
The JVM also supports multithreaded programs, although much of the semantics of con- 
current programs are defined by standard classes, rather than by the JVM itself. 

The JVM was designed to allow efficient, safe execution of (bytecode compiled) Java 
programs. One innovative technique employed to promote efficiency is the use of the byte- 
code verifier. The JVM does not assure type-safe execution by itself. Rather, JVM execution 
is intended to be type-safe when running programs that have been "accepted" by the byte- 
code verifier. The bytecode verifier is intended only to accept programs whose execution on 
the JVM will be type-safe. The standard JVM is defined to elide some type-safety checks 
based on these intended guarantees, using these guarantees to justify optimizations in the 
JVM definition that would not be type-safe without those guarantees. 

Thus, while the JVM execution is intended to be type-safe when running programs ac- 
cepted by the bytecode verifier, the type-safety is not obvious. The JVM is not guaranteed 
to be type-safe when running arbitrary programs. 

The defensive JVM (dJVM) augments the JVM definition with additional run-time checks 
to assure type-safe execution. The definition is intended to be obviously type-safe when run 
on any program. There is no need for a bytecode verifier to screen programs. 

1 . 1 How does the dj VM differ from the JVM? 

The dJVM is obviously type-safe. At least the dJVM is intended to be obviously type-safe. 
In contrast, the JVM is obviously not type-safe by itself. The behavior of the JVM is only 
specified for programs that are (mostly) type-safe. For example, the behavior of the iadd 
instruction is not defined unless the top two words on the operand stack areint values. In 
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contrast, the behavior of iadd on the dJVM is completely defined. 1 

The dJVM is completely defined. Unlike the JVM, the dJVM is completely defined. 

If some constraint (a "must" or "must not") in an instruction description is not 
satisfied at run time, the behavior of the Java Virtual Machine is undefined [em- 
phasis added - RMC]. 
(Lindholm and Yellin, 1996, §6.1, p. 151] 

The effect of every instruction in the dJVM is defined for all possible dJVM states. For every 
state in which the effect of a JVM instruction is defined, the corresponding dJVM instruction 
has the same effect on the the corresponding dJVM state. In addition, in the states for 
which a JVM instruction is undefined, the effect of the corresponding dJVM instruction in 
the corresponding dJVM states is to halt with an error indication. 



Some things we can do with a formal dJVM model: 

• Expose/resolve questions about the JVM behavior (e.g., those not answered in the 
Java Virtual Machine Specifications [Lindholm and Yellin, 1996]). 

• Prove that the JVM is type-safe on programs accepted by the bytecode verifier — this 
is a standard interpreter-equivalence proof. 

• Examine the model's behavior by running test cases (assuming its an executable 



The current model is the first phase of modeling the JVM in ACL2. It was intended to 
demonstrate that such a model could reasonably capture the key properties of the JVM, but 
to be a complete JVM model. It is a rough draft. 

This model includes the basic object-oriented instructions and data structures. It leaves 
out concurrency, interfaces, arrays, and garbage collection. It leaves out floating point data. 
It only includes 103 of the 202 standard JVM instructions. 



1.3.1 Components of JVM included in dJVM 

These are the essential features of the JVM, and were included in the dJVM 0.5 model so that 
this first model would address these key aspects of the JVM. These features also addresses 
the key aspects of object creation and manipulation in this initial phase of the model. 

1 At least the behavior of iadd is defined in all contexts in which such a question makes sense. For example, it 
does not make sense to ask about the effect of executing an iadd instruction if the call stack is empty, because that 
means no method is active to execute the instruction. 



1 2 What use is the dJVM definition? 



model). 



1.3 



Why is this dJVM version 0.5? 



dJVM Specification (vers. 0.5) 
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1.3. WHY IS THIS DJVM VERSION 0.5? 



1. Representation of class objects and class instances. 

A minimal subset of standard Java classes needed to support class definition, object 
creation, and method execution are provided. This includes portions of the standard 
classes: Object and Class. 
Required instructions: new, aconst_null 

2. Instance methods and class methods. 

Required instructions: invokevirtual, invokespecial, invokestatic, return, areturn, 
ireturn. 

3. Instance variables and class variables. 

Required instructions: getfield, putfield, getstatic, putstatic. 

4. Instance initialization methods (i.e., <init> methods). 

5. Primitive types int and long. 

Some of the instructions that manipulate int or long values are included, except those 
related to excluded types (e.g., the i2f instruction, which converts an int integer 
value to a floating point value.) 

i21, i2s, iadd, iand, idiv, iinc , imul, ineg, ior, isub, ixor, 12i, ladd, 
land, ldiv, bipush, sipush 

6. Enough other instructions to run some small examples. 
Such instructions include: 

(a) some load and store instructions 

aload, astore , iload, istore, lload, Istore 

(b) some stack-manipulation instructions 

pop, pop2, dup, dup2, dup_xl, dup_x2 , dup2_xl , dup2_x2, swap 

(c) some control-flow instructions 

goto, if_acmpeq, if _acmpne , if.icmpeq, if_icmpne, if_icmplt, if _icmpge , 
if_icmpgt, if_icmple, ifeq, if ne , if It, ifle, if ge , if null , ifnonnull 



1.3.2 Important Features Left Out For Now 

A number of important features of the JVM have not been included in the dJVM 0.5 model. 
Some of these are candidates for the first extensions to dJVM 0.5. 

1. Dynamic loading of classes. 

2. Class-file verifier and bytecode verifier. 

Technically the class-file verifier and bytecode verifier are not part of the JVM itself. 
However, they do form an important component of most practical Java implementa- 
tions. As such they would be worthy extensions of the dJVM. 
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3. Class initialization methods (i.e., <clinit> methods). 

They are an implicit part of the JVM, because they are invoked implicitly when a class 
is created; they are never invoked explicitly. 

dJVM presumes that all class objects have been constructed and initialized prior to the 
start of execution (i.e., effectively constructed by some primordial loading process). 

4. Interfaces, and interface initialization methods. 

5. Exception handling . 

Including the instructions jsr, jsr_w, ret, and athrow. 

6. Multithreading. 

7. Monitors and synchronization. 

The instructions monitorenter and monitorexit have been be left out, as well as 
the special-case of the method-invocation instructions that deals with synchronized 
methods. 

8. Garbage collection or object finalization. 

Garbage collection is logically a no-op, and so can reasonably be left out of the model. 



1.3.3 Non-essential Features 

This section describes features of the JVM that do not pose problems for modeling or for- 
malization. They have been left out of this initial dJVM model merely to reduce the level of 
effort required. 

1. Arrays and all of the instructions that create or operate on arrays 

2. The data type char 

3. The data types float and double 

ACL2 does not support floating point numbers. 2 So it is unlikely that the dJVM model 
will ever be extended to define floating point operations in the JVM. However, since 
the JVM is defined to perform floating point calculations according to the IEEE Float- 
ing Point Standard, there is little advantage to such an extension. 

4. 16-bit Unicode characters. 

5. The instruction-modifier wide. 

6. Some non-essential instructions. 

(a) ldc 

(b) Many arithmetic instructions. 

2 ACL2 does support arbitrary-precision integers (a.k.a.. bignums) and rational numbers. The axiomatic de- 
scription of rational arithmetic is much more tractable than that of floating point arithmetic. Further, unlike 
floating point numbers, rational numbers obey the normal laws of arithmetic! 
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1.4. WHAT IS A FORMAL MODEL? 



1.3.4 Things not yet in our world 

1. Native methods. 

Native methods are really extensions to the JVM. They are effectively new instruc- 
tions that are executed via the method invocation mechanism, rather than via normal 
instruction dispatch. 

Extending the dJVM to handle native methods would require two steps: 

(a) Extend the representation of methods to allow recording information about na- 
tive methods. 

(b) Extend the method invocation instructions to allow creating a call-frame for a 
native method. 

(c) Extend the instruction dispatcher to recognize when the current method is a 
native method, and invocate the ACL2 description of the method. 

Since each native method is an extension of the dJVM, each new native method will 
require that an additional case be handled by the instruction dispatcher. Each time 
a new native is added to the model, the functions or axioms describing the native 
method must be added to the model and the instruction-dispatcher function must be 
revised to handle invocation of this new native method properly. 3 

2. External system resources (e.g., file systems, networks, etc.) 

Eventually we want to augment our model to describe interactions with external re- 
sources (e.g., file systems and networks). 

3. The _quick instructions. They are implementation-specific optimiziations that do not 
currently fit nicely into the dJVM model. The "quick" instructions anticipate an im- 
plementation based on dispatch vectors. But the current dJVM model performs dy- 
namic lookup, rather than caching method bindings in a dispatch vector. A variant 
of the current model that uses dispatch vectors or other method-caching techniques 
could be developed. 



1.4 What is a Formal Model? 

The dJVM model is built in ACL2. ACL2 is a mathematical logic based on the applica- 
tive subset of Common Lisp [Steele Jr., 1984]. As such it provides a means for describing 
a forma! specification of the dJVM. ACL2 also has a theorem prover for the logic. This the- 
orem prover is the latest in a line of theorem provers built by Bob Boyer and J Moore. 
[Boyer and Moore, 1979; Boyer and Moore, 1988; Kaufmann and Moore, 1994; Kaufmann and Moore. 199 
Thus we can (attempt to) prove properties of these specifications. 

ACL2 allows specifications to be built using function definitions, in the manner of pure 
LISP and other functional programming languages. Since ACL2 is based on a subset of 
Common Lisp, specifications may be executed in an underlying implementation of Com- 
mon Lisp. Thus we can build executable specifications. 

3 Because ACL2 is a first-order logic, the instruction dispatcher must be extended explicitly. ACL2 lacks the 
Common Lisp functions apply and finical 1. Functions are not "first class objects." 
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We prefer to use the terms formal model and executable model, rather than formal specifi- 
cation and executable specification, because these formal artifacts are always models of the 
real computing systems they are meant to describe. Often they are abstract models, leaving 
out some level of detail in order allow formal analysis and proofs about the behavior of the 
model. If it is a good model of the real computing system, then the analysis of the behavior 
of the model should also be predictive about the behavior of the real system. 

1.5 This Report as a Program 

The text of this report is mechanically derived from the dJVM definition accepted and 
compiled by the ACL2 system. In the tradition of Knuth s literate programming, the for- 
mal program and its description were woven together, and subsequently derived por- 
tions can be processed by either a compiler, a theorem prover, or a document formatter. 
[Knuth, 1992; Sewel, 1989] 

Thus, the program text that appears in this report is derived directly from the ASCII 
files used for compilation and execution of the model. This increases our confidence in the 
fidelity of this presentation to the executable model. 

There are two versions of this report. One includes only the executable portion of the 
dJVM definition, and is intended to be more usable as straightforward (and somewhat more 
compact) explanation of the behavior of the dJVM. 

A second version of this report includes the theorems and rewrite rules given to the 
ACL2 theorem prover as part of the model development and to support ACL2 guard ver- 
ification for the model. This is not a complete rendition of the ACL2 proof script because 
some ACL2 directives are suppressed in the text. 4 

ACL2 requires that programs be defined in a bottom-up fashion. Each function must 
be defined (or axiomatized) before it can be used. The presentation in this report follows 
this same basic order. However, some portions of the definition that don't contribute to the 
exposition appear at the end of this document as appendices. These portions include the 
description of bounded-integer arithmetic and the definitions of macros used to build the 
actual instruction definition. The macros are described in the main text, but the details of 
their definitions are relegated to the appendices. 

The File Structure of the Model 

The "source code" for the ACL2 model (and this report) are divided into a number of sep- 
arate files. The files form a dependency hierarchy with most files depending upon defini- 
tions and rules introduced by other files. Here's a list of the files, and roughly bottom-up 
order. Several low-level files that do not contribute to the exposition appear as appendices. 

1. minor-utilities . lisp — Appendix A 

2. preliminaries . lisp — Appendix A 

4 All of the definitions and theorems of the ACL2 proof script are included. Numerous directives enabling and 
disabling rewrite rules are suppressed, as are the directives for including ACL2 "books" (i.e.. libraries). Of course, 
all of the details are available in the ACL2 source files, from which the ET^X 2 C sources for this document were 
derived. 
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3. arith.lisp — Appendix B 

4. primitive-values . lisp — Chapter 4 

5. state . lisp — Chapters 5 through 8. 

6. internal-operations .lisp — Chapter 9 

7. frame -ope rat ion -macro — Appendix D 

8. def ine-inst-macro . lisp — Appendix C 

9. simple-instruct ions-a-h. lisp — Chapter 11 

10. simple-instruct ions-h-i. lisp — Chapter 11 

11. simple-instructions- j-z . lisp — Chapter 11 

12. tableswitch.lisp — Chapter 11 

13. new-instance .lisp — Chapter 12 

14. invoke virtual .lisp — Chapter 13 

15. invokespecial.lisp — Chapter 13 

16. invokestat ic . lisp — Chapter 13 

17. method-returns . lisp — Chapter 13 

18. getf ield. lisp — Chapter 12 

19. getstatic.lisp — Chapter 12 

20. run-djvm.lisp — Chapter 14 

21. initial-djvm.lisp — Chapter 14 



1.6 The Remainder of this Report 

Here's a brief overview of the remainder of this report. 

• Chapters 4 through 5 describe the primitive values and data types manipulated by 
thedJVM. 

• Chapters 6 through 8 build the representation of objects, classes, the call stack, the 
class table, and the heap to yield the full description of the dJVM state. 

• Chapter 9 defines internal operations that manipulate the dJVM state. 

• Chapter 10 describes the the standard structure we will use to define dJVM instruc- 
tions, and the abbreviated forms (macros) that will be used to give those definitions. 

• Chapter 11 defines 98 "simple instructions" — instructions that manipulate only the 
operand stack and local variables without reference to the heap or the class table. 
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• Chapters 12 and 13 describe creation of objects and invocation of methods. 

« Chapter 14 describes the top-level of the dJVM interpreter and the construction and 
initialization of initial dJVM states. 

• The appendices include some low-level definitions that support support the model. 

1.7 Naming, Spelling, and Typeographic Conventions 

This report documents a proof-of-concept for building a formal ACL2 model of the defen- 
sive Java Virtual Machine. Due to the fast pace of the development of this initial model, 
I have not been entirely consistent in the use of naming conventions. In fact, I employed 
several in different sections of the model. Common Lisp and ACL2 are normally not case 
sensitive in resolving function and variable names. The nameCalling-Frame and the name 
calling-frame are considered to be the same. In some places I have taken advantage of 
that, and have used capitalization in an attempt to improve the readability of lone function- 
names. 0 

When function definitions are presented, the name of the function is typeset in a larger 
and different type face to make it stand out. The same style is used for ACL2 events that 
define theorems, data structures, and so on. 

1.7.1 Notes on ACL2, Future Extensions, etc. 

The text notes about ACL2, future extensions of the dJVM model, the Java language, and 
the Java Virtual Machine. These notes are set out from the regular text in the following 



Note on the The first public version of the Java language manual was approximately 35 pages. The 

, ava second version was about 70 pages. The third (and current) version is over 800 pages. 

Language As you ask more and more specific questions, the explanation of the details just seem to 

bpecification multiply. 



The margin note identifies the topic of the note. 



1.7.2 Marginal Cross-references 

The ACL2 definitions that comprise the dJVM 0.5 model appear in the text in af ixed width 
typeface. To facilitate perusal of the definitions cross- references to functions appear in the 
margins. For example, the definition of the function local-method? from page 79 appears 
below. 

(defun lOCal-method? (method-name method-sig class-decl) 
(declare (xargs : guard (and (stringp 

met hod -name) 
(stringp method-sig) 
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Zp (class-decl-p class-decl) ) ) ) 

(java -METHOD- BOUND? method-name 
method-sig 

(CLASS "DECL-METHODS class-decl) ) ) 

The boxes appearing in the margin are cross references for a function that appears on the 
corresponding line of the definition. In this case indicating that the definition ofclass-decl-p 
can be found on page 72, and the definition of java-method-bound? can be found on page 
66. The function to which the cross-reference refers is printed in small capital letters 

(e.g., as JAVA-METHOD-BOUND? and CLASS- D EC L- METHODS above). 



If some function names are underlined, ignore the underlining. The underlining is just Author's 
an indication of where the automatically generated cross-reference mechanism has bro- Note 
ken down. The underlining should be removed in a later draft. 



&TEX2 £ is supposed to put margin notes in the outer margin of the page. However, it Author's 
doesn 't always get it right, as you may be able to observe on this page and elsewhere Note 
in this document. Apparently the page-fill algorithm doesn't reliably communicate with 
the margin note placement mechanism when text is moved to start a new page. I'm not 
sure how to fix this. 



5 I d like to use mixed-case function names throughout the presentation, but don't yet. 
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Chapter 2 



Overview of the dJVM 
Specification 



The dJVM specification is a formal description of a defensive version of the JVM. This de- 
scription of the dJVM 0.5 is complete, in the sense that all questions about the behavior of 
the dJVM can be answered strictly from the ACL2 definitions in this formal description. 1 
However, this report does not by itself present a full explanation of the JVM or the Java 
language. This report is more akin to the first draft of a formal reference manual for the 
dJVM. It serves to answer questions about the virtual machine's behavior in detail, but 
does not attempt to serve as an introduction either to the Java Virtual Machine or the Java 
programming language. The reader should already be familiar with them, or be prepared 
to assimilate them from the formal definitions with the occasioned accompanying brief ex- 
planations. 

We recommend that the reader not already familiar with these topics have ready access 
to The Java Virtual Machine Specification [Lindholm and Yellin, 1996]. Java Virtual Machine 
[Meyer and Downing, 1997] provides an informal, but less authoritative, introduction to 
the JVM. Access to The Java Language Specification [Gosling eta/., 1996] may also be useful. 
The Java Language [Arnold and Gosling. 1996] provides a good introduction to the Java lan- 
guage. 



The dJVM state consists of a set of class declarations, a set of objects (instances of classes), 
a call stack, and a status flag. 



1 Of course, the description of ACL2 and the public libraries are also necessary for a full formal definition of 
the dJVM. Also, this report only describes the initial dJVM 0.5 model, so not all of the ultimate dJVM 1.0 has been 
modeled. 



2.1 The dJVM as a State Machine 



To support multiple threads, the dJVM state would need to be extended to include mul- 
tiple call-stacks with new call-stacks being created each time a new thread was started. 



Future 
Extension 
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The call stack contains stack frames representing each of the method invocations whose 
execution has not yet completed. 

dJVM execution proceeds by taking the next step (i.e., executing the next instruction) 
for the top-most (most recently created) stack frame. If that executes a JVM instruction 
(other than one of the "return" instructions), then the state of that frame is updated (e.g., 
adjusting the local data stack, local variables, and local PC appropriately), and execution 
continues. If the instruction was one of the "return" instructions, then that stack frame is 
popped from the evaluation stack, and any returned-value is pushed onto the data stack of 
the new top-most stack frame. If an error occurred during execution of the step, then the 
dJVM 0.5 halts with status indicating what error occurred. 



Future 
Extension 



The dJVM 0.5 model does not support throwing or handling exceptions. When an 
exception would be thrown by the JVM, the dJVM halts. 

The dJVM 0.5 should be extended to support throwing and catching exceptions. 



2.2 Overview of dJVM State 

The dJVM state includes four basic components: 

• a heap of objects, 

• a call stack, which records information about currently executing methods. 

• a class table mapping class names to class definitions, and 

• a status flag, indicating whether the dJVM is halted. 

The call stack contains call frames. Each call frame corresponds to a method invocation 
that has not yet completed. 



Future 
Extension 



The dJVM 0.5 state can be extended to support multi-thread computations simply by 
adding multiple call stacks. 



A call frame contains: 

• an operand stack 

• a vector of local variables (called "registers" in the early JVM specification) 

• a method 
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2.3 Instructions as State Transitions 

2.4 An Executable Interpreter 

2.5 Naming conventions 

Instruction definitions are usually named in the style of djvm-execute-XJX with XXX re- 
placed with the instruction name. 

2.5.1 Standard Pieces of Instruction Definitions 

Instruction definitions are broken into several parts. For each instruction we will (normally) 
define one function to correspond to each of these parts. By convention, each of these 
functions have standard names and take the standard argument lists: 

1. (xxx-vf f-inst? inst) 

This function tests whether its argument is a well-formed dJVM instruction, where 
xxx stands for the name of the instruction whose form is to be checked. 

2. (.xxx -proper- arg-types? inst frame) 

This function tests whether the types of the instruction arguments and operands in the 
frame are properly typed. Instruction arguments are the values that appear within 
an instruction. In addition to instruction arguments, most instructions also take ad- 
ditional operands from the operand stack or from local variables. 

Note that this test is made with respect to the current frame, but without respect to 
objects in the heap. This is meant to correspond to information that could be checked 
by a bytecode verifier at load time. 

3. (xxx-resolve-args inst djvm) 

This function is a place-holder for potential resolution of instruction arguments or 
class initialization. In all of the current instruction definitions it is a no-op. 

4. (xxx-proper-arg-values? inst resolved-d j vm) 

This function tests whether the values of the instruction arguments and operands are 
appropriate. For example, this function checks that operands that reference objects in 
the heap identify instances of the appropriate reference types (or null). In contrast, 
the xxx-proper-arg-types? test could only check that the operand was some refer- 
ence type, since resolving the actual reference type requires accessing the object in the 



This function may accept values that are defined to trigger run-time exceptions. For 
example, it checks that the stack operands of the integer division instruction idiv are 
integers, but does not check that the denominator is non-zero. The idiv instruction is 
defined to signal a run-time exception if the denominator is zero. 

These tests may include tests normally considered part of class, field, and method 
resolution. 
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5. (djvm-execute-xxx-optimized instruction djvm) 

This function defines the behavior of thexxx instruction assuming that all of the tests 
just mentioned succeeded. Thus, we know that the instruction is well-formed, that 
its arguments and operands all have proper types and values, and proper reference 
values (for operands that are of reference types). 

6. (xxx-proper-result-type-? inst new-djvm) 

For instructions that leave a result on the operand stack, this function checks that the 
result is of an appropriate type. For example, idiv-proper-result-type? checks 
that after normal completion of the idiv instruction the top-most operand on the 
stack is of type int. 

7. (djvm-execute-xxx-inst inst djvm-with-pc-incremented) 

This is the defensive definition of the instruction. After making the tests mentioned 
above it applies the optimized version, and checks the result type afterward. 

Appendix C describes the forms and macros used for defining instructions in more detail. 
Instruction Formats 

Some instructions include small integer arguments. When an JVM instruction takes an ar- 
gument that is an index into the constant pool, the corresponding dJVM instruction takes 
the corresponding value or values from the constant pool. For example, the JVM instruc- 
tion getfield takes as its single argument an index identifying a CONSTANT_Fieldref in 
the constant pool. The dJVM instruction getf ield takes three arguments, the three string 
constant items (class name, field name, and type signature) identified in the constant pool. 
Here is an example of the dJVM instruction: 



where "Point" is the name of a class of the instance to be accessed, "x" is the name of the 
field to be accessed, and "I" is the type signature of that field. As well as distributing the 
constant-pool entries into the instructions, the dJVM uses symbolic opcodes, rather than 
the numeric bytecode values. Both of these choices were made to make the dJVM states 
easier to examine and construct. They also help to simplify the dJVM model somewhat, 
allowing us to concentrate on the richer parts of the definition. 
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Primitive Values 



The dJVM manipulates data values. Within the dJVM state each data value has an associ- 
ated type. A type defines the set of values that a variable may hold, that an input value or 
output value must be within. 

The Java language defines seven primitive numeric types and allows declaration of 
reference types, whose values refer to class instances or null. 1 

We use the term primitive values to include both numeric values (i.e., values of the prim* 
itive numeric types) and reference values. 

4. 1 Primitive Types 

The Java language has seven primitive types. They are defined in terms of the numeric 
values that variables of these types are permitted to hold. 

1. byte values are in the range [ — 2 7 2 7 — 1 ] 

2. short values are in the range { — 2 15 2 15 — 1 ] 

3. int values are in the range [ — 2 31 2 31 - 1 ] 

4. long values are in the range [ — 2 63 2 63 — 1 J 

5. char values are in the range [0 .. 2 16 — 1 ] 

6. float (not used in the dJVM) 

7. double (not used in the dJVM) 

The JVM has direct support for four of these primitive types (int, long, float, and 
double), as well the reference type. The JVM does not directly support either byte, char, 
or short integer types. The "narrower" integer types (byte, short, and char) are not di- 
rectly supported, but are represented as int values during processing. 2 The JVM operand 

'The value null is defined in Java to be a distinct type, rather than a value shared by each reference type. At 
the level of the JVM the value null is a value that is shared by all reference types. 

2 The JVM provides support for storing byte, short, and char values in arrays. The dJVM 0.5 model does not 
support arrays. 
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stack and local variables are defined to hold 32-bit values. So 64-bit long values that are 
stored on the operand stack or in local variables must be represented as two 32-bit entries. 

The dJVM does not support floating point variables (i.e., types float or double). 

Java also admits the reference type, which permits references to class instances. 



4.2 Tagged Values 

Within the dJVM operand values are stored as tagged values. Each of the primitive 
data values appearing in the dJVM state is actually a pair, consisting of a type tag and 
a primitive value of the appropriate type. Each primitive value is tagged with its type 
(int, long, or ref). 

The JVM specifies that certain internal data is stored as abstract words. Each abstract 
word can at least hold values corresponding to 32-bit two s-complement integers (i.e., cor- 
responding to the int primitive type). The operand stack and local variables, which will 
be components of call frames (section 8.4. page 82) are defined to hold abstract words Be- 
cause a long value will not fit into a single abstract word, long values must be stored as 
two entries on the operand stack or as two local variables. 



T72/s will affect atomicity of dJVM operations when the dJVM is extended to model 
concurrency, because access to multiple words may require multiple memory references, 
and so can be interleaved with other operations. Be warned! 



The predicate tv-p tests whether its argument is a tagged value — that is, a pair whose 
first element is a type tag (e.g.. such as : int). which satisfies the predicate jvm-type'? and 
whose second element is any atomic value (e.g., an integer) appropriate to the type tag. 

We use the macro def-tv to define recognizers for several sorts of tagged-value terms 
Each tagged value is a type tag and a value satisfying an appropriate predicate. The acces- 
sor tv-tag and tv-val extract the tag and value (respectively) from a tagged-value. 

The form 

(def-tv tv-ref -p (:ref unsigned-int-p) ) 



defines the recognizer tv-ref -p. Subsequently the term (tv-ref -p alpha) has the 
ing 

(and (weak-tv-p alpha) 

(equal (tv-tag alpha) :ref) 
(unsigned-int-p (tv-val alpha))) 



The test (weak-tv-p alpha) checks that we can safely apply tv-tag and tv-val to access 
the components of alpha. 
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(def macro def-tv (name car-and-cadr-p) 

(declare (xargs : guard (and (consp c ax- aird- cadr-p) 

(symbolp (car car-and-cadr-p) ) 
(symbolp (cadr car-and-cadr-p))))) 
(let ((car-p (car car-and-cadr-p)) 

(cadr-p (cadr car-and-cadr-p))) 
' (def macro ,name (x) 
(list 'and 

(list 'weak-tv-p x) 
, (if (keywordp car-p) 

'(list 'equal (list ' tv-tag x) , car-p) 
'(list » , car-p (list 'tv-tag x))) 
, (if (keywordp cadr-p) 

'(list 'equal (list 'tv-val x) , cadr-p) 
'(list ' , cadr-p (list >tv-val x) )))))) 



Reference values are addresses of heap objects. Since they can reside in the operand Note on JV 

stack, and values in the operand stack must be representable in abstract words, heap Semantics 
addresses are implicitly limited to 32-bits. 



Below are recognizers for the dJVM tagged values. The tags : long-top-half and : long- 
-bot-half identify the two parts of a long value when it is represented as a pair of abstract 
words. The tag : long is used when the long integer value is represented as a single tagged 
value. 3 

(def-tv tV-int-p (:int int-value-p)) 
(def-tv tV-IOng~p (:long long-value-p) ) 
(def-tv tV-rsf-p (:ref unsigned-int-value-p) ) 

(def-tv tV-long-tOp-half-p (: long-top-half unsigned-int-value-p) ) 
(def-tv tV-IOng-bOt-half-p (:long-bot-half unsigned-int-value-p) ) 



Appendix B of this document defines bounded integer arithmetic for int and long in- 
teger values. The predicate int-value-p recognizes integer values in the range permitted 
by the type int. Similarly the predicate long-value-p recognizes integer values permitted 
by the type long. The predicate unsigned-int-value-p recognizes integer values in the 
range [0 2 32 — 1]. The JVM instructions do not support unsigned arithmetic operations, 
but unsigned 32-bit integers are used in the dJVM to represent parts of long values values 
and heap addresses. 

(defun Value-Of-type? (type-tag value) 
(case type-tag 

(:int (int-value-p value)) Q 
(:long (long-value-P value)) □ 

3 Obviously such a tagged long integer value cannot reside on the operand stack, or in a local variable. But it 
will be able to reside in an instance field, as we will see in section 4.3. page 27. 
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(:ref (unsigned- int-value-p value)) 
( ( : Long-Top-Half 
:Long-Bot-Half 

) (UNSIGNED-INT-VALUE-P Value)) 

(otherwise nil) 
)) 



The function make-tv constructs a tagged-value pair from a type tag and a value. It does 
not check that the value is appropriate for the given type tag. In the contexts in which we 
use make-tv, we know that the value is in fact appropriate, and ACL2'S guard verification 
will generally enforce this requirement. 4 

As mentioned above, the predicate weak-tv-p tests whether its argument has the form 
of a tagged value, suitable for accessing via tv-tag and tv-val. Concretely, it checks that 
its argument is a proper list of two elements. 

(defun msk&'tV (tag val) 
(declare (xargs :guard t)) 
(list tag val)) 

(defun Weak-tV-p (x) 

(declare (xargs :guard t)) 
(and (consp x) 

(consp (cdr x)) 

(not (consp (eddr x))))) 

(defun tV-tag (x) 

(declare (xargs : guard (weak-tv-p x))) 
(first x)) 

(defun tV-Val (x) 

(declare (xargs : guard (weak-tv-p x))) 
(second x)) 



(defthm weak-tv-p-make-tv 

(weak-tv-p (make-tv tag val))) 

(defthm make-tv-pieces 

(and (equal (tv-tag (make-tv x y)) x) 

(equal (tv-val (make-TV x y)) y)) 
: hints (("Goal" :in-theory (enable make-tv tv-tag tv-val)))) 



4 Tagged values will ultimately be stored on the operand stack, in local variables, or in an instance field. All of 
these are required to be properly-tagged values, and guard verification will enforce this requirement. 
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4.3 Stack Values and Field Values 

We distinguish between values that are permitted on the operand stack (or in local vari- 
ables) and vaJues that may appear in instance and class fields. The distinction concerns the 
handling of long integer values. The operand stack always manipulates 32-bit data. 5 So 
when a 64 -bit integer (long) value must be pushed onto the stack, it is divided in half, and 
the two halves are pushed onto the stack individually. However, we do not make the same 
restriction on long values stored in an object field. A field declared to hold a long value 
can hold the entire 64-bit integer value. 

The Java Virtual Machine Specification describes stack values as: 

No mention has been made of the storage requirements for values of various 
Java Virtual Machine types, only ranges those values may take. ...The Java 
Virtual Machine defines an abstract notion of a word that has a platform-specific 
size. A word is large enough to hold a value of type byte, char, short, int, 
float, reference, returnAddress, or to hold a native pointer. Two words are 
large enough to hold values of the larger types, long and double. Java's run- 
time data areas are all defined in terms of these abstract words. 
[Lindholm and Yellin, 1996. §3.4, p. 61] 

Our discussion in this section is slightly more concrete than that, in that we specify that 
stack values must be representable with words of only 32 bits. This addition is intended to 
make the dJVM model more closely resemble current-day JVM implementations. Further, 
during execution of the dJVM model, we divide long values precisely into two 32-bit halves 
when storing the long value on the operand stack or into local variables. Again this is 
intended to make execution states more closely resemble common implementations. 



We should first define the specifications and functions axiomatically. and then provide Author's 
executable versions. This will clarify the formal requirements from the executable im- Note 
plementation of the dJVM. 



We refer to values that are permitted on the operand stack as stack values, and we refer to 
values that are permitted in object fields as field values. Observe that these two sets are not 
disjoint. Tagged values of type :ref and : int are both legal stack values and field values. 

When data moves between object fields and the operand stack, long values will have to 
be converted between their 64-bit integer representation and the corresponding two 32- 
bit "half-long" values. We will see this conversion as part of thegetfield, putfield, 
getstatic, and putstatic instructions 

Implementors are free to decide the appropriate way to divide a 64-bit data 
value between two local variables. 
[Lindholm and Yellin, 1996, §3.6.1, p. 67] 

Implementors are free to decide the appropriate way to divide a 64-bit data 
value between two operand stack words. 
[Lindholm and Yellin, 1996, §3.6.2, p. 67] 



5 Of course in the dJVM the 32-bit data values are always tagged. 
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Author's Since these descriptions appear in two separate sections, presumably the implementor is 

Note free to choose differently for the stack and for local variables. This would significantly 

complicate the instructions for dealing with loading and storing double-word values. 

and this possibility is not addressed in those instructions. 



Author's 
Note 



Does theJLS orJVMS say anything about how values are stored in object fields? 

I think the implementor is free to do what he likes in the object representation. 

However they do state that accessing long and double fields is not an atomic operation. 
Since long and double are stored as two words in the stack, we know that such accesses 
will at least make two references to the local frame, and this may be enough to imply that 
such accesses may not be atomic — regardless of how the long or doubl e field values are 
actually stored. 

They explicitly state that byte, short, and char values are stored as "word" values on 
the stack and in local variables (except for arrays). They define a notion of an abstract 
word of unspecified size, but capable of representing all int values. The JVM always 
reserves two words for long and double values, even though on some implementations 
(e.g., platforms with 64-bit words) a single word might be capable of representing long 
and double values. 



The JVM specification does not state how long values should be represented in fields 
within an instance. We have chosen to represent long values as single entries in an instance. 
Thus, an instance field may contain a value of any type except the long-top-half and 
long-bot-half types, which are only permitted on the operand stack and in local variables. 
Collectively we refer to the values permitted in instance fields as field values. The predicate 
f v-p recognizes legal field values. 



(defnn fV-p (x) 

(declare (xargs : guard t)) 
1 25 I (or (tv-int-p x) 

1 25 I (tv-long-p x) 

1 25 I (tv-ref-p x))) 



Local variables and the operand stack may hold values of any type, except long. Long 
values must be represented using two smaller values, one of type long-top-half and one 
of type long-bot-half. Collectively we refer to these values as legal stack values. The 
predicate sv-p recognizes legal stack values. 



(defun SV-p (x) 

(declare (xargs : guard t)) 
1 25 J (or (tv-int-P x) 

I 25 I (tv-ref-P x) 

1 25 1 (tv-long-top-half-p x) 

i 25 I (tv-long-bot-half-p x))) 
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(defthm sv-p-is-weak-tv-p-forward 

(implies (sv-p x) 

(WEAK-TV-P x)) 

ihints (("Goal' 1 :in-theory (enable sv-p))) 
rrule-classes ( : forward-chaining) > 

(defthm sv-p-if-fv-p-and-not-long 

(implies (and (fv-p x) 

(not (tv-long-p x))) 
(sv-p x)) 

: hints (("Goal" :in-theory (enable fv-p sv-p)))) 

( d ef t hm s v-p-recomposed-s v 

(and (implies (sv-p x) 

(sv-p (make-tv (tv-tag x) (tv-val x)))) 
(implies (and (sv-p tv) 

(equal tag (TV-TAG tv)) 
(equal val (tv-VAL tv))) 
(sv-p (make-tv tag val))))) 

(defthm s v-p-ma ke - tv-in t 

(implies (iNT-VALUE-P val) 

(sv-p (make-tv :int val)))) 

(defthm sv-p-remake-tv-ref-p 

(implies (tv-ref-P x) 

(SV-P (MAKE-TV :REF (tv-val x))))) 

(defthm sv-p-make-tv-unsigned-int-case 

(implies (and (unsigned-int-value-p val) 

(member tag ' (:ref : long-top-half : long-bot-half ) ) ) 
(sv-p (make-tv tag val)))) 

S+NOT-NEEDED 

(defthm sv-p-make-tv-ref 

(implies (unsigned-int-value-p x) 
(SV-P (MAKE-TV :REF x))) 
ihints (("Goal" :in-theory (enable sv-p)))) 

(defthm sv-p-make-tv-long-xxx-haff 

(implies (integerp x) 

(and (sv-p (make-tv : long-bot-half (LONG-BOT-HALF x))) 

(sv-p (make-tv : long-top-half (long-top-half x))))) 
ihints (("Goal" :in-theory (enable tv-tag 

tv-val 
sv-p 
)))) 



Define predicates that recognize lists of stack values (sv-listp) and lists of field values 

(fv-listp). 

(deflist SV-liStp (1) 
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sv-p) 

(defthm sv-listp-is-true-listp-forward 

I 29 1 (implies (sv-listp x) 

(true-listp x)) 
: rule-classes ( : forward- chaining) ) 

(in-theory (disable sv-listp-true-listp) ) 

(deflist fV-Hstp (1) 
fv-p) 



(defthm fv-fistp-is-true-listp-forward 

I JboVf 1 (implies (fv-listp x) 

iP* (true-listp x)) 

: rule-classes ( : forward-chaining) ) 

(in-theory (disable f v-listp-true-listp) ) 

(defthm SV-p-deffl 
1 2 $ 1 (implies (or (tv-ref-P x) 

I 25 I (tv-int-p x) 

I 25 "I (tv-long-top-half-p x) 

1 25 I (tv-long-bot-half-p x)) 

QD (sv-p x))) 

(defthm fv-p-defn 

1 ^ 5 1 (implies (or (tv-ref-p x) 
I 25 \ (tv-int-p x) 

I 25 1 (tv-long-p x)) 

EM3 (fv-p x))) 



The function tv-ref-listp recognizes a list of (tagged) object references. 



(defiist tv-ref-listp (d 

tv-ref-p) 



Below are type prescription lemmas giving type information for applications of tv-val to 
tagged values. Obviously the type yielded by tv-val depends on the type-tag of the tagged 
value. 

First we observe that all of the standard tagged-values have integers as their tv-val 
component. Then we give the type information as type -prescription lemmas and provide 
tighter integer-bounds in rewrite rules. 



(defthm tv-val-type-prescription 

> 28 I (implies (or (sv-p x) 
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nn 
m 



(fv-p x)) 
(integerp (tv-val x))) 
: rule-classes (: rewrite : type-prescription) ) 

(defthm naturalp-W-val-type-prescription 

(implies (or (tv-ref-p x) 

(tv-long-top-half-p x) 
(tv-long-bot-half-p x)) 
(natnralp (tv-val x)))) 

(defthm int-value-p-tv-int-p 

(implies (tv-INT-P x) 

(int-value-p (tv-val x)))) 

(defthm long-value-p-tv-long-p 

(implies (tv-long-p x) 

(long-value-p (tv-val x)))) 

(defthm unsigned-int'Value-p-tv-ref'P 

(implies (tv-ref-p x) 

(unsigned-int-value-p (tv-val x)))) 

(defthm unsigned-int-value-p-tv-long-top-half-p 

(implies (tv-long-top-half-p x) 

(unsigned- int-value-p (tv-val x)))) 

(defthm unsigned-int-value-p-tv-long-bot-half-p 

(implies (tv-long-bot-half-p x) 

(unsigned-int-value-p (tv-val x)))) 

(defun tv-one-word-p (x) 

(declare (xargs : guard t)) 
(or (tv-int-p x) 
(tv-ref-p x))) 

(defun tV-tWO-WOrd-p (x) 
(declare (xargs : guard t)) 
(or (tv-long-top-half-p x) 
(tv-long-bot-half-p x))) 



(in-theory (disable make-tv tv-tag tv-val)) 



4.4 The Null object 



We should also define functions that give the default value for each primitive type - 
including (ref-to-null) for reference types. 

Note: there is no default initial value for :addr values. We only need default values for 
declared fields, and fields cannot be declared of typeaddress. 



Author's 
Note 
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(defun addr-of-null o 

o) 

(defun ref'tO-PUll () 
GZD (make-tv :ref (addr-of-null) ) ) 

(defun ref-to-null-p u) 

\ 3bov * ) (equal x (REF-TO-NULL) ) ) 



4.5 64-bit wide types 

Wide-type-tags lists the type tags associated with 64-bit data values. Wide values can only 
be stored on the stack or in local variables if they are split into two parts that will fit within 
the 32-bit size of individual stack entries and local variables. For each type tag denoting 
a wide (64-bit) value, we define two associated type tags that denote two 32-bit values to 
be associated with the 64-bit value. We call these two 32-bit values the "top half" and the 
"bottom half" of the wide value. 

We define functions for manipulating 64-bit wide values, for splitting them into two 
separate 32-bit values (their top and bottom "halves") and for combining the two halves 
back into the single wide-value. 

Future The dJVM 0.5 model only supports 64-bit wide integers (i.e., the long data type). A 

Extension future extension could support additional 64-bit types (e.g., doub le.) We would then 

define a general notion of wide values, that woul d include all 64 -bit field values. 

(defun tV-tOp-half-p (x) 

(declare (xargs : guard t)) 
I 25 I (tv-long-top-half-p x)) 

(defun tV-bot-half-p (x) 

(declare (xargs :guard t)) 



2U (tv-long-bot-kalf-p x)) 

(defun tV-Wlde-p (x) 
25 I (tv-long-p x)) 



(defun parts-of-same-wide-type (top-haif bot-haif) 

(declare (xargs : guard (and (sv-p top-half) 

(sv-p bot-half)))) 

(case (tv-tag top-half) 

(: long-top-half (equal (tv-tag bot-half) ' : long-bot-half ) ) 
)) 
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(defun tv-long-top-half <*) 

(declare (xargs : guard (tv-long-p x))) 

(make-tv ' : long-top-half (long-top-half (tv-val x)))) 

(defnn tV-long-bot-half (x) 

(declare (xargs : guard (tv-long-p x))) 

(make-tv ' : long-bot-half (long-bot-HALF (tv-val x)))) 

(defthm sv-p-tv-long-top-half 

(sv-p (tv-long-top-half x)) 

:hints (("Goal" :in-theory (enable sv-p 

tv-long-top-half 

value-of -type?) ) ) ) 

(defthm sv-p-tv-long-bot-half 

(sv-p (tv-long-bot-half x)) j 
: hints (("Goal" :in-theory (enable sv-p 

tv-long-bot-half 

value-of -type?) ) ) ) 

(defun tv-wide-top-half (x) 

(declare (xargs : guard (and (fv-p x) [ 

(tv-wide-p x)))) [ 

(case (tv-tag x) [ 

(:long (tv-long-top-half x)))) [ 

(defun tv-wide-bot-half ( X ) 

(declare (xargs : guard (and (fv-p x) [ 

(tv-wide-P x)))) [ 

(case (tv-tag x) [ 

(:long (TV-LONG-BOT-HALF x) ) [ 

)) 

(defthm tv-wide-half-type-prescription 

(implies (tv-wide-p x) [ 
(and (sv-p (tv-wide-top-half x)) [ 
(sv-p (tv-wide-bot-half x))))) [ 

(defun make-tv-wide-value (top-haif bot-haif) 

(declare (xargs : guard (and (tv-top-half-p top-half) [ 

(TV-BOT-HALF-P bot-half) [ 
( PARTS- OF- SAME-W I DE-TYPE top-half bot-half)))) [ 

(case (tv-tag top-half) 

(: long-top-half (make-TV J :long [ 

(make-long (tv-val top-half) (tv-val bot-half)))) f 

)) 

(defthm make-tv-wide-value-type-prescription 

(implies (and (tv-top-half-p x) £ 
(tv-bot-half-p y) £ 

(PARTS-OF-SAME-WIDE-TYPE X y) ) Q 

(tv-wide-p (make-tv-wide-value x y)))) q 
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urn 
nn 
run 



Below are a few general recognizers for properly-typed tagged-values, for lists of tagp e d- 
values, and for lists of reference values. 845 



(defun tv-wide-value-p ( x ) 

C&O (tv-long-p x)) 



(defthm tv-long-half-facts 

-^-j (implies (tv-long-p x) 



rS (and (TV-LONG-TOP-HALF-P (t V-long-top-half X» 

j==| (tV-top-half-p (TV-LONG-TOP-HALF x)) 

r^-, (sv-p (TV-LONG-TOP-HALF x)) 



H3T1 (equal (tv-tag (tv-long-top-half x)) long-top-half ) 

rjjg-i ; SV "P (TV-LONG-TOP-HALF x) ) 

(UNSIGNED- INT-VALUE-P (tv-val (t v-long-top-haTf x) ) > 
(TV-LONG-BOT-HALF-P (t V-long-bot-half x)) 

(tv-bot-half-p (TV-LONG-BOT-HALF x) ) 

( SV ~P (TV-LONG-BOT-HALF x)) 

^ equal (tv-tag (tv-long-bot-half x) ) long- bot -half) 

(sv "P (tv-long-bot-half x)) 

(unsigned- int-value-p (tv-val (tv-long-bot-half x))))) 
:hints (("Goal" :in-theory (enable make -tv 

sv-p 
tv-tag 
tv-val 
)))) 

(in-theory (disable tv-long-top-half tv-long-bot-half)) 

(defthm weak-tv-p-tv-long-top-half 

(weak-tv-p (tv-long-top-half x)) 
: hints (("Goal" : in-theory (enable tv-long-top-half)))) 

(defthm weak-tv-p-tv-Iong-bot-half 

(weak-tv-p (tv-long-bot-half x)) 

: hints (("Goal" : in-theory (enable tv-long-bot-half)))) 

(defthm wide-half-facts 

j (implies (and (sv-P x) 

f=j (TV-WIDE-VALUE-P x) ) 

r=\ (and (sv ~P (tv-wide-top-half x)) 

— (sv-p (tv-wide-bot-half x))))) 

(defnn jvm-type-tags () 

' (:int :long : long-top-half : long-bot-half :ref)) 



(defun jvm-type-tag? ( X ) 

(memberp x ( jvm-type-tags) ) ) 
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(defthm jvm-type-tag-if-tv-p 

(~an (implies (or (SV-P x) 

(FV-P x)) L 

( JVM -TYPE-TAG? (tv-tag x)))) C 

(defiist weak-tV'listp u) 

weak-tv-p) 

(defthm weak-tv-listp-is-true-listp-forward 

(implies (veak-tv-listp x) C 

(true-listp x) ) 
: rule-classes ( : forward- chaining) ) 

(in-theory (disable weak-tv-listp-true-listp) ) 

(defthm naturalp-listp-is-true-listp-forward 

(implies (naturalp-li stp x) C 

(true-listp x)) 
: hints (("Goal" : in-theory (enable natnralp-listp) ) ) 
: rule-classes -.forward-chaining) 



We often have to reason about values satisfying tv-p and weak-tv-p. To avoid additional 
clutter in our proofs, we disable those definitions. So, we must define rules for how those 
concepts should relate in proofs. Any value that satisfies tv-p must also satisfy weak-tv-p. 
So we define a forward-chaining rule that says "whenever a value is known to satisfy tv-p, 
assert that it also satisfies weak-tv-p." We state a similar rule relating weak-tv-listp to 
tv-listp. 

(defthm weak-tv-p-if-sv-p-forward 

(implies (sv-P x) t 
(WEAK-TV-P x)) t 
: rule-classes ( : forward-chaining) ) 
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(implies (fv-p x) t 
(weak-tv-p x)) [ 
: rule-classes ( : forward- chaining) ) 

(defiist weak-tv-listp a) 

weak-tv-p) 

(defthm weak-tv-listp-if-sv-l/st-p-forward 

(implies (sv-listp x) i 

(WEAK-TV-LISTP x) ) t 

: rule-classes ( : forward-chaining) ) 

(defthm weak-tV'listp'if-fv-list-p-forward 

(implies (fv-listp x) 1 
(WEAK-TV-LISTP x) ) [ 
: rule-classes ( : f orward-chaining) ) 



BNSDOC1D <y=> I > 





CHAPTER 4. PRIMITIVE VALUES 



4.5. 1 Extended Type Tags 

So far we have used tags to mark data values used in the stack and in object fields. Now we 
extend the notion of tags to include abstract tags that allow specification of larger sets of data 
values. These extended tags will be used to describe constraints on part of the dJVM state. 
For example, the extended tag : one-word-type will be used to indicate that a tagged value 
must be of a one-word data type (i.e., anything but a two-word data type). These extended 
type tags will be used as part of the pattern language we use to define the "simple" dJVM 
instructions later on. 

(defiist jvm-type-tag-listp co 

jvin-type-tag?) 
(in-theory (disable j vm-type-tag-listp-true-listp) ) 

(defnn extended-type-tags o 

' ( : same 

: one-word-type 
: not-top-half 
:not-bot-half 



(defun extended-type-tag? oo 

(or ( J VM -TYPE-TAG? x) 

(memberp x (extended-type-tags)))) 

(defiist extended-type-tag-listp a) 

extended- type-tag?) 



The tags used in primitive tagged values can be used as type specifications. The use of a 
particular type in a type specification indicates that the corresponding tagged value should 
be of the indicated type. This is sufficient to discuss the primitive types, but is not adequate 
to specify reference types — that is, values that refer to instances in the heap. The function 
extended- j vm-type? extends the standard type tags to allow the type-tag : ref to be paired 
with a string. (In our use later, the string will be required to be a class name, but for the 
moment we only impose the syntactic requirement.) 

(defun extended-jvm-type? ( x ) 



)) 



C2D 



(if (WEAK-TV-P x) 

(and (equal (tv-tag x) ' :ref ) 
(stringp (tv-val x))) 
(jvm-type-tag? x))) 



(defiist extended-jvm-type-listp u) 



extended-jvm-type?) 
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(in-theory (disable extended- j vm-type-listp-true-listp) ) 



(in-theory (disable extended-type-tag-listp-true-listp) ) 
(in-theory (disable valne-of -type?) ) 



Well-formed operand stacks. A well-formed operand stack is a sequence of stack val- 
ues with the added constraint that every long-top-half value must immediately precede a 
long-bot-half value, and every long-bot-half value must immediately follow a long-top-half 
value. All well-formed JVM states will satisfy this predicate. Since the dJVM relies on run- 
time tests to validate the well-formedness of the JVM state, we will not rely on states being 
well formed. Each operation that alters the operand stack will check that it is not given an 
ill-formed stack and that its stack manipulations do not leave an ill-formed stack. 



This is the sort of global state-invariant we expect the JVM to preserve during execu- Future 
tion. Such properties are proven inductively; if an initial state satisfies the property and Extension 
every step (executing a single instruction) preserves the property, then the property is 
invariant during execution. 

The dJVtvf 0.5 model has not been proven to preserve this global invariant. After such a 
proof is done, some of the run-time defensive checks could be elided. 

(defun valid-stack? (stk) 

(declare (xargs : guard (sv-LISTP stk) C 
: guard-hints (("Goal" : in-theory (disable veak-tv-p) ) ) ) ) 

(if (endp stk) 
t 

(if (tv-one-word-p (car stk)) C 
(valid-stack? (cdr stk)) Qi 
; ; It's part of a two-word type . . . 

(and (tv-long-TOP-HALF-P (car stk)) C 
(consp (cdr stk)) 

(tv-long-bot-half-p (cadr stk)) C 
(valid-stack? (cddr stk)))))) HL 
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(defun method-type-sig-p-internal (sig o 

"Parse sequential field-types in a signature 

until we hit the end of the string or a right parenthesis." 
(declare (xargs : guard (and (stringp sig) 

(natnralp i) 
(<= i (length sig))) 
rmeasure (max 0 (- (length sig) (acl2-count i))) 
: guard-hints (("Goal* 1 :in-theory (disable length))))) 
(if (and (natnralp i) 

(< i (length sig))) 
(if (equal (char sig i) #\)) 

(return-type-sig-p sig (1+ i)) { 
(let ((next-field-index (field-type-sig-internal-p sig i))) [ 
(and (not (null next-field-index)) 

(method-type-sig-p-internal sig next-field-index)))) [ 

nil)) 



(defun method-type-sig-p ( S i g ) 

"Recognize a method type-signature." 
(declare (xargs : guard t)) 
(and (stringp sig) 

(> (length sig) 0) 

(equal (char sig 0) #\() 

(method-type-sig-p-internal sig 1))) 



(defthm stringp-if-method~type-sig-p 

(implies (method-type-s ig-p x) 

(stringp x)) . 
: rule-classes ( : forward-chaining) ) 



7.5 Type-Tag Lists 

Now we define a translator from a type-signature string to a list of type tags, which is more 
easily used for run-time type-checking. 

Note that the type-signature of a single field may translate into a list of one or two type 
tags, depending on whether the type-signature represents a one-word type (e.g.. int) or a 
two-word type (e.g., long). 

Note also that type-list-f or-f ield-type-sig does not return a list of symbols. Refer- 
ence types are represented as the cons-pair :ref and the class name (as a string). We define 
the predicateextended-jvm-type-listp, which is similar to the predicate jvm-type-listp, 
to recognize these extended type-lists. 

(defun type-list-for-field-type-sig-intemal (sig i) 

(declare (xargs : guard (and (stringp sig) 

(natnralp i) 
(<= i (length sig))))) 

(if (< i (length sig)) 
(case (char sig i) 
(#\I >(:int)) 
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(#\J ' (: long-top-half : long- bot -half) ) 

(#\L (list (list >:ref (field-type-sig-class-name sig (1+ i))))) 
(otherwise '(;error))) 
>(:error))) 

The function type-list-f or-f ie ld-type -sig translates a field type-signature into a list of 
type tags as described above. The tag list is used for run-time type-checking when accessing 
instance fields and when invoking or return from methods. 

(defun type-Iist-for-field-type-sig (sig) 

"Translate a field type-signature to a list of extended-type tags." 
(declare (xargs : guard (and (stringp sig) 

(field-type-sig-p sig)))) 

(TYPE-LIST-FOR-FI ELD— TYPE-S IG _ INTERNAL sig 0)) 

(defun type-list-for-method-parameters-internai ( S i g i) 

(declare (xargs .guard (and (stringp sig) 

(naturalp i) 
(<= i (length sig))) 
:measure (max 0 (- (length sig) (acl2-count i))) 

(if (or (not (naturalp i)) 

; ; (not (stringp sig)) 
(>= i (length sig))) 

nil 

(let ((next-field-index (field-type-sig-internal-p sig i))) 
(if (not (null next-field-index)) 

(append (type-list-for-field-type-sig- internal sig i) 

(type-list-for-method-parameters-internal sig next-field-index)) 
(if (equal (char sig i) #\)) 
nil 

' (:error)))))) 

The function type-list -f or-method-parameters returns a list of extended- type tags for a 
list of stack values to be a well-typed parameter list satisfying the given type-signature. 

(defun type-list-for-method-parameters (sig) 

(declare (xargs : guard (and (stringp sig) 

(method-type-sig-p sig)))) 

(if (and (> (length sig) 0) 

(equal (char sig 0) #\()) 

(type-list-fdr-method-parameters-internal sie l) 

>(:error))) 

(in-theory (disable field-type-sig-p 
method-type-sig-p 
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type-list -f or-method-paramet ers 
type-list-for-field-type-sig) ) 
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Chapter 9 



Manipulating the dJVM State 



This chapter defines the internal operations that alter the dJVM state. The dJVM instruc- 
tions will be defined in terms of these operations. 



9.1 Checking Stack Signatures 

Most Java instructions require that the top few elements of the stack contain values of spec- 
ified data types. For example, the integer addition operation (iadd) requires that the top 
two elements of the stack contain integer values. The predicate stk-sig-top? is used to 
state just such requirements. The precondition for iadd would be stated as: 

(stk-sig-top? stk-sig :int :int). 



The predicate stk-sig-top? is defined as a macro, so that it can take a variable number Remark 
of arguments. on 

ACL2 



Note on reference types: Although the an extended-type tag list, such as returned by the 
function type-list-f or-f ield-type-sig- internal, includes both :ref and the specified 
class name for a reference type, the function stk-sig-top? only checks that the stack value 
is a reference value, stk-sig-top? is intended to check the basic type-safety preconditions 
for JVM instructions. 

While some JVM instructions require an argument to be a reference value, some of them 
require (as a precondition) that value be a reference to an instance of particular class. For 
example, the athxow instruction has a precondition that its argument be a reference type 
and that the referenced object is an instance of class java.lang.Throwable. The bytecode 
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verifier checks both of these preconditions. The bytecode verifier attempts to resolve the the 
declared class of the object being thrown. If resolution fails, the bytecode verification fails 
In contrast, some other instructions, such ascheckcast and instanceof . take class names as 
arguments; these instruction argument values are represented as strings 1 and they are not 
resolved to a class object until execution time. 

We provide a bottom-up description of these macros. 



Author's 
Note 



J don t believe that unquote-list-elements is needed any longer. Initially I thought 
thts would be used in top-level code, and hadn t decided whether type labels should be 
quoted or not in that context. 

However, currendy this is only used in thedef ine-djvB-operation macro And those 
arguments are not explicitly quoted. So. I should pull this out and recompile and rever- 



\ above \ 



(defun unquote-list-elements (list) 

(declare (iargs : guard (true-listp list))) 
(if (endp list) 
nil 

(cons (if (and (true-listp (car list)) 

(equal (caar list) 'quote)) 
(cadar list) 
(car list)) 
(unquote-list-elements (cdr list))))) 

(defnn stksig-top-type-Hstp < x ) 

(declare (xargs .guard (true-listp x))) 
(if (endp x) 
t 

(and (or (symbolp (car x)) 

(and (consp (car x)) 

(eql (car (car x) ) ':ref))) 
(STK-SIG-TOP-TYPE-LISTP (cdr x))))) 



In definition of assert-value-typed-properly below, the value of the parameter variable 
is expected to be an ACL2 expression that accesses a typed-value within the dJVM state 
(e.g., an element of the operand stack, or a local variable). The macro manipulates ACL2 
forms, composing new forms from old ones. 

We use an extended notion of type specifier here, so that we can assert more abstract 

s?Sfiere aw * * ° f 3 p3rtiCular ^ (e ^' :int >- The extended 



rone-word- type accepts any primitive type whose values occupy one word (i e are not 
naif of a two-word value). 



inst^o e n JVM StringS r6Side C ° nStam PO ° l f ° r * e C,3SS - In * e dJVM the stri "g are pan of the 
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Chapter 10 



The Standard Form of Instructions 



10.1 Java's Shared-Memory Model 



dJVM 0.5 does not include threads and synchronization. So it does not need to model Future 
shared-memory. However, we mention some of the issues related to shared-memory Extension 
which may be dealt with in a future extension of the dJVM. 



The Java language includes threads and synchronization. In support of them the lan- 
guage includes the concepts of locks and monitors. It also includes an explicit model of 
memory access that addresses how each thread in a multithreaded program accesses a main 
memory shared by all threads. 

The language definition specifies that there is a main memory that is shared by all threads, 
and that each thread has its own working memory. The main memory contains the "master 
copy" of every variable. It also contains a lock associated with each object in main mem- 
ory. Each thread operates on values from its working memory, copying values between its 
working memory and main memory as necessary. Chapter 17 of the Ja va Language Specifi- 
cation addresses when such copying is necessary, as well as which memory operations are 
atomic, and ordering requirements between program actions (e.g., the level of reordering 
of actions within a single thread and the interleaving of actions between multiple threads). 

10.2 Standard Parts of Instruction Definitions 

Since we are defining the defensive Java Virtual Machine, each instruction must perform 
various tests to assure that its arguments and results are well-formed and type-correct. For 
each instruction we define a function that implements that instruction. That function per- 
forms all the required tests and (if the tests succeed) updates the state of the dJVM to reflect 
execution of the instruction. Since each instruction-implementation function requires these 
tests and halts with similar errors if any test fails, the body of each follows the same form. 

Each instruction implementation consists of six steps: 
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1. Check that the instruction is syntactically well-formed. 

(We could include checks that static local variable indices are less than the number of 
local varibles specified in the method declaration. But that would require the addi- 
tional context of the method declaration, which we will skip here. This index range- 
checking is done in step 4 below.) 

2. Check that the arguments are of the proper number and type. 

For objects, this merely checks that the operand is a reference type. It does not check 
the actual class of the operand. 

3. Resolve any referenced classes, fields, or methods if necessary. 

(This step would perform dynamic class-loading if it were supported.) 

4. Check that the argument values are permissible. 

This tests any required semantic preconditions for the instruction. For example, the 
idiv instruction must check that the divisor is non-zero, and thegetf ield instruction 
that the object reference is not null. 

5. Execute the instruction and update the pc register. 

6. Check that any result values are permissible. 

For example, method invocations and field accesses should leave a value of the re- 
quired type on the operand stack. This test is degenerate for instructions that always 
yield a fixed-type result, but is required for "generic" instructions (e.g., getfield, 
new, etc.) 

These tests should always be redundant in a type-safe program. Since the dJVM is 
intended to detect type errors, these checks are made explicitly. However, these tests 
should be provably true if the loaded JVM methods are all type-safe. 

7. Check that the operand stack hasn't overflowed. 

8. Check that the updated pc register is valid if the current method is a bytecoded 
method. 1 

9. Check that if the call stack is empty, then the dJVM status is : halted. 

Strictly speaking this is not a requirement of the JVM definition. In the dJVM the 
return is defined to set the machine status to : halted if it is exiting from the only 
frame on the call stack. No other instruction that completes normally should result 
in an empty call stack. The other return instructions (ireturn, areturn, etc.) return a 
result value to a calling frame, and so they should never be executed unless there are 
at least two frames on the call stack. An unhandled error or exception could also halt 
the computation, but the dJVM does not yet handle exceptions. 
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Author's Where do exceptions tit in??? Any instruction can throw an exception. 

Note 



The JVMS claims to document and order all exceptions that can arise as a result of con- Author's 
stant pool resolution. So we must be careful that we honor that order! Note 



A Java Virtual Machine throws an object that is an instance of a subclass of the 
class VirtualMachineError when an internal error or resource limitation pre- 
vents it from implementing the semantics of the Java Language. [Emphasis added.] 
The Java Virtual Machine specification cannot predicate where resource limita- 
tions or internal errors may be encountered and does not mandate precisely 
when they can be reported. Thus, any of the virtual machine errors listed as 
subclasses of VirtualMachineError . . . may be thrown at any time during the 
operation of the Java Virtual Machine. 
[JVMS §6.3. p. 152] 



To some extent the JVMS description seems to intermingle the idea that the JVM is tied Author's 
to Java semantics and that the JVM is a separately specified machine. The quote above is Note 
just one example. 



For each instruction we define a separate function to accomplish each of these steps. By 
convention each of these functions takes a standard argument list as follows: 

1. (getf ield-vff-inst? inst) 

2. (getf ield-proper-arg-types? inst frame) 

This predicate takes the instruction and the current frame. It can check the type of 
values in local variable and on the operand stack, but it cannot examine objects in the 
heap. 

3. (getf ield-resolve-args inst djvm) 

4. (getf ield-proper-arg-values? inst resolved-djvm) 

This predicate takes the instruction and the full dJVM state (after any class resolution, 
which in an extended dJVM might trigger dynamic class loading) . Thus this predicate 
can examine heap objects and check their class. 



! The JVM does not define the value of the pc register when the current method is a native method. So it only 
makes sense to ask whether thepc is valid when executing a bytecoded method. 

The dJVM 0.5 does not currently support execution of native methods. However, to permit future support for 
native methods the dJVM 0.5 defines a representation of nauve methods in stack frames. Thus, for example, after 
execution of a return instruction the current method may be either a bytecoded method or a native method. Of 
course, if it's a native method then the dJVM 0.5 will subsequently halt, since it cannot currently execute native 
methods — but the return instruction will have completed normally. 
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XP 000679974 Java uses a sophisticated class-checking mechanism to ward off 
, breaches in security. By Gary McGraw and Edward Felten 

Java Security and Type Safety 




I ava's ability to download, 
! integrate, and execute code 
! from a remote computer is 
a double-edged sword. On 
the positive side, the use of Java enables 
a computer to obtain new capabilities 
with little user intervention. In addition, 
Java requires no installation of hard-to- 
rrack-down and dubiously secure plug- 
in files. On the negative side, however, 
Java's intricate machinations leave a com- 
puter vulnernable to attack. A hostile Java 
jpplet could stealthily tamper with a host 
system's files or siphon off private data 
without the user's being aware of the dam- 
age until it's too late. 

Java's designers did their best to make 
such malicious activities impossible by 
implementing a security model. This se- 
curity model performs a number of checks 
before allowing a downloaded applet 
to execute. (For additional information 
on Java security, see "Plugs for Java's Se- 
curity Holes" on page 76.) 

Java securiry relies on three prongs of 
defense: the Byte-Code Verifier, the Ap- 
plet Class Loader, and the Securiry Man- 
ager. Together, these three prongs per- 
form load and run-rime checks to restrict 
file-system and network access, as well 
as restrict access to browser internals. 
Each of these prongs depends in some 
way on the others. Each part must do 
its job properly for the securiry model 
to function correctly. 

The Security Triad 

The figure "Java Securiry Triad" above 
shows how the three prongs of defense 
fit into the Java framework. The Byte- 
Code Verifier is the first prong of the Java 
securiry model. When a Java source pro- 
gram is compiled, it's converted to plat- 
form-independent Java byte code. The 
Verifier then checks that the untrusted 
outside code "plays by the rules" before 
it's allowed to run. 



The Verifier checks byte code at a num- 
ber of different levels. The simplest test 
ensures that a .class file (i.e., a byte- 
code file) has the correct format. On a less 
basic level, the Verifier applies a built-in 
theorem prover to each method. The the- 
orem prover helps ensure that byte code 



as a new class. The Class Loader deter- 
mines when and how an applet can add 
classes to a running Java environment. 
Part of the Class Loader's job is to make 
sure that rhe applet doesn't install code 
that replaces important components of 
rhe Java run-time environment. 



Java Security Triad 
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Java performs several safety checks before a 
downloaded applet can execute. 



does not forge pointers, violate access re- 
strictions, or access objects using incor- 
rect type information. The verification 
process, in concert with the definition 
of the Java language, helps to establish a 
base set of securiry guarantees. 

Java's second prong of security de- 
fense is the Applet Class Loader. Typically 
supplied by a browser vendor, it loads 
all applets and the classes that they ref- 
erence. When an applet is loaded from 
the network, rhe Applet Class Loader re- 
ceives the binary data and instantiates it 



In general, a running Java environment 
can have many active Class Loaders, each 
defining its own namespace. Namespaces 
allow Java classes to be separated into 
distinct kinds, according to where they 
originate. In other words, a namespace 
is a type-safe portion of memory with 
classes that are associated with a specific 
Class Loader. 

The third prong of the Java securiry 
model is the Securiry Manager, which 
restricts the ways in which an applet can 
use visible interfaces. Thus, the Securiry 
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Manager implements a good portion of 
the entire security model. It's a single 
module that performs run-time checks 
on dangerous methods, such as those 
for file or network access or those that 
define new Chss Loaders. 

Code in the Java library consults the 
Security Manager whenever a dangerous 
operation is about to be attempted. The 
Security Manager then has a chance to 
veto the operation by generanng a Secu- 
rity Exception. Decisions made by the Se- 
curity Manager rake into account which 
Class Loader loaded the requesting class. 
Built-in classes arc given more privilege 
rhan classes that have been loaded over 
the network (e.g., applets). 

The three parts of the Java security 
model were created to enforce type safe- 
ty, which means that a program can per- 
form particular operations only on par- 
ticular kinds of objects. Therefore, Java 
programs are prevented from accessing 
memory in inappropriate ways. 

More specifically, every piece of mem- 
ory is part of some Java object, and each 
object has some class. For example, a 
calendar management applet might use 
such classes as Date, Appo.nrment, Alarm, 
and GroupCalendar. Each class defines 
a specific set of operations that are al- 
lowed to operate on ob,ects of that class. 
Fn the calendar management example, 
the Alarm class might define a turnQn 

operation, but the Date class would not 

allow tu^nOn to occur. 

Why Type Safety Matters 

To understand why type saferv matters 
consider the folio w.ng, slightly contrived,' 
example. The calendar management 
applet mentioned above defines a class 
Alarm, wh,ch is represented in memorv, 
J* shown in the figure -Type Safety'" 
above. Alarm defines an operation turn • 
On, which sets the first field to true. The 
Java run-time library defines another 
class called Applet, whose memory lay- 
out is shown in the figure. Note that the 
first field of Applet is fileAcceiSAl - 
5 owes, which says whether or not the 
applet is allowed to access files on the 
hard disk. 

Now suppose that a program tries to 
apply the t u rnOn operation to an Applet 
ob,ect. If the turnOn operation is per- 
mitted, the program sets the first field 
or the object to true. Unfortunate! v, since 
the target object is reallv of rvpe Applet 
setting the first field to true allows the 



applet to access the file system. The appl er 
is then allowed— incorrecrly— to mod- 
ify and even delete files. 

How Java Enforces 
Type Safety 

Java labels every object by associating a 
class tag with it. One simple way to en- 
force type safety would be to check an 
object's type tag before every operation 
on it to make sure that the object's class 
allows such an operation. This approach 
is called dynamic type checking. 

Although this scheme works, it's inef- 
ficient. Programs end up running slowly 
because the system spends a lot of time 
checking class tags. To improve perfor- 
mance, Java uses static type checking, 



an effective static type checker that elim- 
inates almost all the tag-checking opera- 
tions from Java programs. The result is 
a program that's type-safe bur that runs 
quite efficiently. 

Type Confusion 

There is only one problem with Java's 
static type-checking strategy: If s com- 
plicated. Although Java's designers ob- 
viously got the overall strategy right, 
a great many details have to be correct 
for type safety to be enforced. An error 
in any of these details leaves a tiny, albeit 
crucial, hole in Java's rype-saferv armor. 

A clever cracker who finds such a hole 
can launch a type-confusion attack. This 
is done with a Java applet careful) v de- 
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Java ensures that malicious programs can't 
gain access to system resources. 



which is more complicated but more ef- 
ficient than dynamic type checking. Stat- 
ic type checking is where the Java sv S - 
tem looks ara program before it runs and 
carefully deduces the results of the tag- 
checking operations. If Java can figure 
our that a particular tag-checking opera- 
tion will always succeed, then there's no 
reason to do it. The check can safelv be 
removed, thus speeding up the program. 

Java's designers carefully crafted the 
Java language and byte-code formats to 
facilitate static type checking. Each piece 
of byte code is a binary representation 
of an assembly-like language with op 
codes and operands. 

But Java op codes always take rype-spe- 
cific arguments. There are no "generic" 
operands that take multiple types in the 
same operand position, as is the case with 
processor assembly languages. 

This, and other properties of byte 
code, make static type checking easier 
to implement. The Byte-Code Verifier is 



signed to leverage a tiny type-enforce- 
ment hole into a complete system pene- 
tration. The attacker can set up a situation 
hke the aforementioned Alarm/Applet 
example, in which the program has one 
type of object but the Java system thinks 
the object has some other type. 

Because the Verifier normally prohibits 
such actions, type-confusion errors are 
usually the result of bugs in the Java im- 
plementation, it is hoped that such prob- 
lems will disappear as the implementa- 
tion is debugged and refined. O 
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(57) A program interpreter for computer programs 
written in a bytecode language, which uses a restricted 
set of data type specific bytecodes. The interpreter, prior 
to executing any bytecode program, executes a bytecode 
program verifier procedure that verifies the integrity of a 
specified program by identifying any bytecode instruction 
that would process data of the wrong type for such a byte- 
code and any bytecode instruction sequences in the 
specified program that would cause underflow or over- 
flow of the operand stack. If the program verifier finds 
any instructions that violate predefined stack usage and 
data type usage restrictions, execution of the program 
by the interpreter is prevented. After pre-processing of 
the program by the verifier, if no program faults were 
found, the interpreter executes the program without per- 
forming operand stack overflow and underflow checks 
and without performing data type checks on operands 
stored in operand stack. As a result, program execution 
speed is greatly improved. 
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Description 



BACKGROUND OF THE INVENTION 
1 . Field of the Invention. 

The present invention relates generally to the use of computer software on multiple computer platforms which use 
distinct underlying machine instruction sets, and more specifically to an efficient program interpreter and method which 
efficiently handles data type usage checks and operand stack usage checks. 



As represented generally in Figure 1, in a typical prior art networked computer system 100, a first computer 102 
may download a computer program 103 residing on a second computer 104. In this example, the first user node 102 
will typically be a user workstation having a central processing unit 106, a user interface 108, a primary memory 110 
(e.g.. random access memory) for program execution, a secondary memory 1 12 (e.g., a hard disc) for storage of an 
operating system 113, programs, documents and other data, and a modem or other communication interface 1 14 for 
connecting to a computer network 1 20 such as the Internet, a local area network or a wide area network. The computers 
102 and 104 are often called "nodes on the network" or "network nodes." 

The second computer 104 will often be a network server, but may be a second user workstation, and typically would 
contain the same basic array of computer components as the first computer. 

In the prior art, after the first computer 102 downloads a copy of a computer program 103 from the second computer 
1 04, there are essentially no standardized tools available to help the user of the first computer 1 02 to verify the integrity 
of the downloaded program 1 03. In particular, unless the first computer user studies the source code of the downloaded 
program, it is virtually impossible using prior art tools to determine whether the downloaded program 103 will underflow 
or overflow its stack, or whether the downloaded program 1 03 will violatef iles and other resources on the user's computer. 

A second issue with regard to downloading computer software from one computer to another concerns transferring 
computer software between computer platforms which use distinct underlying machine instruction sets. There are some 
prior art examples of platform independent computer programs and platform independent computer programming lan- 
guages. However, the prior art also lacks tools for efficiently executing such platform independent computer programs 
while guarding against violation of data type usage restrictions and operand stack usage restrictions. 

SUMMARY OF THE INVENTION 

The present invention concerns a program interpreter for computer programs written in a bytecode language, to be 
commercialized as the OAK language, which uses a restricted set of data type specific bytecodes. All the available 
source code bytecodes in the language either (A) are stack data consuming bytecodes that have associated data type 
restrictions as to the types of data that can be processed by each such bytecode, (B) do not utilize stack data but affect 
the stack by either adding data of known data type to the stack or by removing data from the stack without regard to 
data type, or (C) neither use stack data nor add data to the stack. 

The interpreter or the present invention according to a preferred embodiment, prior to executing any bytecode pro- 
gram, executes a bytecode program verifier procedure that verifies the integrity of a specified program by identifying any 
bytecode instruction that would process data of the wrong type for such a bytecode and any bytecode instruction 
sequence program that would cause underflow or overflow of the operand stack. If the program verifier finds any instruc- 
tions that violate pre-defined stack usage and data type usage restrictions, execution of the program by the interpreter 



The bytecode program verifier aspect of the present invention according to a preferred embodiment includes a virtual 
operand stack for temporarily storing stack information indicative of data stored in a program operand stack during the 
execution a specified bytecode program. The verifier processes the specified program by sequentially processing each 
bytecode instruction of the program, updating the virtual operand stack to indicate the number, sequence and data types 
of data that would be stored in the operand stack at each point in the program. The verifier also compares the virtual 
stack information with data type restrictions associated with each bytecode instruction so as to determine if the operand 
stack during program execution would contain data inconsistent with the data type restrictions of the bytecode instruction, 
and also determines if any bytecode instructions in the specified program would cause underflow or overflow of the 
operand stack. 

To avoid detailed analysis of the bytecode program's instruction sequence flow, and to avoid verifying bytecode 
instructions multiple times, all points (called multiple-entry points) in the specified program that can be immediately 
preceded in execution by two or more distinct bytecodes in the program are identified. Preferably, at least one of the two 
or more distinct bytecodes in the program will be a jump/branch bytecode. During pre-processing of the specified pro- 
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gram, the verifier takes a "snapshot" of the virtual operand stack immediately prior to each multiple-entry point (i.e.. 
subsequent to any one of the preceding bytecode instructions), compares that snapshot with the virtual operand stack 
state after processing each of the other preceding bytecode instructions for the same multiple-entry point, and generates 
a program fault if the virtual stack states are not identical. 
5 After pre-processing of the program by the verifier, if no program faults were found, the interpreter executes the 

program without performing operand stack overflow and underflow checks and without performing data type checks on 
operands stored in operand stack. As a result, program execution speed is greatly improved. 

BRIEF DESCRIPTION OF THE DRAWINGS 

10 

The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments 
of the invention and, together with the description, serve to explain the principles of the invention, wherein: 

Figure 1 depicts two computers interconnected via a network. 

15 

Figure 2 depicts two computers interconnected via a network, at least one of which includes a bytecode program 
verifier in accordance with the present invention. 

Figure 3 depicts data structures maintained by a bytecode verifier during verification of a bytecode program in 
20 accordance with the present invention. 

Figure 4 represents a flow chart of the bytecode program verification process in the preferred embodiment of the 
present invention. 

25 Figure 5 represents a flow chart of the bytecode program interpreter process in the preferred embodiment of the 

present invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

30 Reference will now be made in detail to the preferred embodiments of the invention, examples of which are illustrated 
in the accompanying drawings. While the invention will be described in conjunction with the preferred embodiments, it 
will be understood that they are not intended to limit the invention to those embodiments. On the contrary, the invention 
is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of 
the invention as defined by the appended claims. 

35 Referring now to a distributed computer system 200 as shown in Figure 2, a first computer node 202 is connected 
to a second computer node 204 via a computer communications network such as the Internet 220. The first computer 
node 202 includes a central processing unit 206, a user interface 208, primary memory (RAM) 210, secondary memory 
(disc storage) 212, and a modem or other communication interface 214 that connects the first computer node 202 to 
the computer communication network 220. The disc storage 212 stores programs for execution by the processor 206, 

40 at least one of which is a bytecode program 221 which is of executable form. For the purposes of this description, it will 
be assumed that the first computer node 202 receives the bytecode program 221 from the second computer node 204 
via the computer communications network 220 using file transfer protocols well known to those skilled in the art. 

In the preferred embodiment, the bytecode program is written as an OAK application, which when compiled or 
interpreted will result in a series of executable instructions. A listing of all the source code bytecode instructions in the 

45 OAK instruction set is provided in Table 1 . The OAK instruction set is characterized by bytecode instructions that are 
data type specific. Specifically, the OAK instruction set distinguishes the same basic operation on different primitive data 
types by designating separate opcodes. Accordingly, a plurality of bytecodes are included within the instruction set to 
perform the same basic function (for example to add two numbers), with each such bytecode being used to process 
only data of a corresponding distinct data type. In addition, the OAK instruction set is notable for instructions not included. 

so For instance, there are no "computed goto" instructions in the OAK language instruction set, and there are no instructions 
for modifying object references or creating new object references (other than copying an existing object reference). 
These two restrictions on the OAK instruction set, as well as others, help to ensure that any bytecode program which 
utilizes data in a manner consistent with the data type specific instructions in the OAK instruction set will not violate the 
integrity of a user's computer system. 

55 In the preferred embodiment, the available data types are integer, long integer, short integer (16 bit signed integer), 
single precision floating point, double precision floating point, byte, character, and object pointer (sometimes herein 
called an object reference). The "object reference" data type includes a virtually unlimited number of data subtypes 
because each "object reference" data type can include an object class specification as part of the data type. In addition, 
constants used in programs are also data typed, with the available constant data types in the preferred embodiment 
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comprising the data types mentioned above, plus class, f ieldref, methodref, string, and Asciz. all of which represent two 
or more bytes having a specific purpose. 

The few bytecodes that are data type independent perform stack manipulation functions such as (A) duplicating one 
or more words on the stack and placing them at specific locations within the stack, thereby producing more stack items 

5 of known data type, or (B) clearing one or more items from the stack. A few other data type independent bytecode do 
not utilize any words on the stack and leave the stack unchanged, or add words to the stack without utilizing any of the 
words previously on the stack. These bytecodes do not have any data type restrictions with regard to the stack contents 
prior to their execution, and all but a few modify the stack's contents and thus affect the program verification process. 
The second computer node 204, assumed here to be configured as a file or other information server, includes a 

io central processing unit 218, a user interface 228, primary memory (RAM) 222, secondary memory (disc storage) 224, 
and a modem or other communication interface 234 that connects the second computer node to the computer commu- 
nication network 220. The disc storage 224 stores programs for execution by the processor 218 and/or distribution to 
other computer nodes. 

The first and second computer nodes 202 and 204 may utilize different computer platforms and operating systems 
15 236, 237 such that object code programs executed on either one of the two computer nodes cannot be executed on the 
other. For instance, the server node 204 might be a Sun Microsystems computer using a Unix operating system while 
the user workstation node 202 may be an IBM compatible computer using an 80486 microprocessor and a Microsoft 
DOS operating system. Furthermore, other user workstations coupled to the same network and utilizing the same server 
204 might use a variety of different computer platforms and a variety of operating systems. 
20 In the past, a server 204 used for distributing software on a network having computers of many types would store 

distinct libraries of software for each of the distinct computer platform types (e.g., Unix, Windows, DOS, Macintosh, etc.). 
Thus, different versions of the same computer program might be stored in each of the libraries. However, using the 
present invention, many computer programs could be distributed by such a server using just a single, bytecode version 
of the program. 

25 As shown in Figure 2, the first computer node 202 stores in its secondary memory 21 2 a bytecode verifier program 

240 for verifying the integrity of specified bytecode programs and a bytecode interpreter 242 for executing specified 
bytecode programs. Alternately, or in addition, the first computer node 202 may store a bytecode compiler 244 for con- 
verting a verified bytecode program into an object code program for more efficient execution of the bytecode program 
221 than by the interpreter 244. 

30 The bytecode verifier 240 is an executable program which verifies operand data type compatibility and proper stack 
manipulations in a specified bytecode (source) program 221 prior to the execution of the bytecode program 221 by the 
processor 206 under the control of the bytecode interpreter 242. Each bytecode program 103 has an associated verifi- 
cation status value 245 that is initially set to False when the program is downloaded from another location. The verification 
status value 245 for the program is set to True by the bytecode verifier 240 only after the program has been verified not 

35 to fail any of the data type and stack usage tests performed by the verifier 240. 

During normal execution of a program by an interpreter, the interpreter must continually monitor the operand stack 
for overflows (i.e., adding more data to the stack than the stack can store) and underflows (i.e., attempting to pop data 
off the stack when the stack is empty). Such stack monitoring must normally be performed for all instructions that change 
the stack's status (which includes most all instructions). For many programs, stack monitoring instructions executed by 

40 the interpreter account for approximately 80% of the execution time of an interpreted computed program. 

In addition, the downloaded bytecode program may contain errors involving the data types of operands not matching 
the data type restrictions of the instructions using those operands, which may cause the program to be fail during exe- 
cution. Even worse, a bytecode program might attempt to create object references (e.g., by loading a computed number 
into the operand stack and then attempting to use the computed number as an object handle) and to thereby breach 

45 the security and/or integrity of the user's computer. 

Use of the bytecode verifier 240 in accordance with the present invention enables verification of a bytecode program's 
integrity and allows the use of an interpreter 242 which does not execute the usual stack monitoring instructions during 
program execution, thereby greatly accelerating the program interpretation process. 

so The Bytecode Program Verifier 

Referring now to Figure 3, the execution of the bytecode program verifier 240 will be explained in conjunction with 
a particular bytecode program 340. The verifier 240 uses a few temporary data structures to store information it needs 
during the verification process. In particular, the verifier 240 uses a stack counter 342, a virtual stack 344, a virtual local 
55 variable array 345, and a stack snapshot storage structure 346. 

The stack counter 342 is updated by the verifier 240 as it keeps track of the virtual stack manipulations so as to 
reflect the current number of virtual stack 320 entries. The virtual stack 344 stores data type information regarding each 
datum that will be stored by the bytecode program 340 in the operand stack during actual execution. In the preferred 
embodiment, the virtual stack 344 is used in the same way as a regular stack, except that instead of storing actual data 
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and constants, the virtual stack 344 stores a data type indicator value for each datum that will be stored in the operand 
stack during actual execution of the program. Thus, for instance, if during actual execution the stack were to store three 
values: 

HandleToObjectA 
5 5 
1 

the corresponding virtual stack entries will be 
R 
I 

w I 

where "FT in the virtual stack indicates an object reference and each "I" in the virtual stack indicates an integer. Further- 
more, the stack counter 342 in this example would store a value of 3, corresponding to three values being stored in the 
virtual stack 344. 

Data of each possible data type is assigned a corresponding virtual stack marker value, for instance: integer (I), 
is long integer (L), single precision floating point number (F), double precision floating point number (D), byte (B), short 
(S). and object reference (R). The marker value for an object reference will often include an object class value (e.g., 
R:point, where "point" is an object class). 

The virtual local variable array 345 serves the same basic function as the virtual stack 344. That is, it is used to 
store data type information for local variables used by the specified bytecode program. Since data is often transferred 
20 by programs between local variables and the operand stack, the bytecode instructions performing such data transfers 
and otherwise using local variables can be checked to ensure that the local variables accessed by each bytecode instruc- 
tion are consistent with the data type usage restrictions on those bytecode instructions. 

While processing the specified bytecode program, for each datum that would be popped off the stack for processing 
by a bytecode instruction, the verifier pops off the same number of data type value off the virtual stack 342 and compares 
25 the data type values with the data type requirements of the bytecode. For each datum that would be pushed onto the 
stack by a bytecode instruction, the verifier pushes onto the virtual stack a corresponding data type value. 

One aspect of program verification in accordance with present invention is verification that the number and data 
type of the operands in the operand stack status is identical every time a particular instruction is executed. If a particular 
bytecode instruction can be immediately preceded in execution by two or more different instructions, then the virtual 
30 stack status immediately after processing of each of those different instructions must be compared. Usually, at least one 
of the different preceding instructions will be a conditional or unconditional jump or branch instruction. A corollary of the 
above "stack consistency" requirement is that each program loop must not result in a net addition or reduction in the 
number of operands stored in the operand stack. 

The stack snapshot storage structure 346 is used to store "snapshots" of the stack counter 342 and virtual stack 
35 344 to enable efficient comparison of the virtual stack status at various points in the program. Each stored stack snapshot 
is of the form: 

SC, DTI, DT2, DT3 DTn 

where SC is the stack counter value, DT1 is the first data type value in the virtual operand stack, DT2 is the second data 
type value in the virtual operand stack, and so on through DTn which is the data type value for the last possible item in 
40 the virtual operand stack. 

The stack snapshot storage structure 346 is bifurcated into a directory portion 348 and a snapshot storage portion 
350. The directory portion 348 is used to store target instruction identifiers (e.g., the absolute or relative address of each 
target instruction) while the snapshot portion 350 is used to store virtual stack 344 snapshots associated with the target 
instruction identifiers. 

45 "Target" instructions are defined to be all bytecode instructions that can be the destination of a jump or branch 

instruction. For example, a conditional branch instruction includes a condition (which may or may not be satisfied) and 
a branch indicating to which location (target) in the program the execution is to "jump" in the event the condition is 
satisfied. In evaluating a conditional jump instruction, the verifier 300 utilizes the stack snapshot storage structure 346 
to store both the identity of the target location (in the directory portion 348) and the status of the virtual stack 344 (in the 

so snapshot portion 350) just before the jump. The operation of the stack snapshot storage structure 346 will be explained 
in greater detail below in conjunction with the description of the execution of the bytecode verifier program. 

As was described previously, the bytecode program 350 includes a plurality of data type specific instructions, each 
of which is evaluated by the verifier 300 of the present invention. The bytecode program 350 includes instructions for 
stack manipulations 352 and 354 (push integer onto the stack and pop integer from the stack respectively), a forward 

55 jump 356 and its associated target 364. a backwards jump 366 and its associated target 362. and a do loop 358 and its 
associated end 360 (which may be an unconditional or conditional branch instruction, depending on the type of do loop). 
Since the verifier 240 of the preferred embodiment of the present invention only seeks to verify stack manipulations and 
data type compatibilities, the operation of the bytecode verifier can be explained using this representative set of instruc- 
tions. 
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Referring now to Figures 4A-4G, and Appendix 1 , the execution of the bytecode verifier program 240 will be described 
in detail. Appendix 1 lists a pseudocode representation of the verifier program. The pseudocode used in Appendix 1 is, 
essentially, a computer language using universal computer language conventions. While the pseudocode employed 
here has been invented solely for the purposes of this description, it is designed to be easily understandable by any 
computer programmer skilled in the art. 

As shown in Figure 4A, the downloaded bytecode program is loaded (400) into the bytecode verifier 300 for process- 
ing. The verifier 300 creates (402) the virtual stack 344 and creates the virtual local variable array 345 by designating 
arrays of locations in memory to store operand and local variable data type information. Similarly, the verifier creates 
(404) the stack snapshot storage structure by designating an array of locations in memory to store snapshot information. 
Finally, the verifier designates (406) a register to act as a stack counter 342 for keeping track of the number of virtual 
stack entries. 

A first pass is made through the bytecode program in order to extract target information associated with conditional 
and un-conditional jumps and loop instructions. In this first pass the verifier 300 sequentially processes all the instructions 
(steps 408, 410, 412), and for each instruction that is a conditional or unconditional jump (step 414) a representation of 
the target location for the jump is stored (step 416) in the directory portion 348 of the stack snapshot storage structure 
346, unless (step 418) the target location has already been stored in the directory 348. For instance, the absolute or 
relative address of the target instruction may be stored in the next available slot of the directory 348. All other types of 
bytecode instructions are ignored on this first pass. 

After all the instructions in the program have been processed, the directory 348 is preferably sorted to put the target 
locations noted in the directory in address sequential order. 

Referring again to Figure 3, for the purposes illustration the stack snapshot storage structure 346 has been loaded 
with the information which would have been stored in the directory portion 348 as if the first pass of the verification had 
been completed based on the bytecode instructions shown in bytecode program 350. Specifically, the directory portion 
has been loaded with the addresses associated with all of the targets of the conditional and unconditional jumps resident 
in the bytecode program. 

Referring now to Figure 4B. a second pass through the bytecode program is initiated in order to verify proper use 
of the operand stack and of data types by the bytecode program. The first instruction of the bytecode program is selected 
(430) and the verifier first checks (432) to see if the address for the selected instruction has been stored in the directory 
portion 348 of the stack snapshot storage structure 346 in the first pass described above. 

If the address of the selected instruction is in the directory 348, indicating that the selected instruction is the target 
of a conditional or un-conditional jump, the verifier checks (434) to see if an associated stack snapshot has been stored 
in the snapshot portion 350 of the stack snapshot storage structure 346. If a stack snapshot has not been stored (indi- 
cating that the instruction is a target of a backward jump), then the contents of the virtual stack and the stack counter 
are stored (436) in the stack snapshot storage structure 346. The snapshot contains information on the status of the 
virtual stack just before the execution of the instruction being processed, including a data type value for each datum that 
has been pushed onto the stack. 

If a stack snapshot has been stored for the currently selected instruction (indicating that a jump instruction associated 
with this target instruction has already been processed), then the verifier compares (438) the virtual stack snapshot 
information stored in the snapshot portion 350 of the stack snapshot storage structure 346 for the currently selected 
instruction with the current state of the virtual stack. If the comparison shows that the current state and the snapshot do 
not match, then an error message or signal is generated (440) identifying the place in the bytecode program where the 
stack status mismatch occurred. In the preferred embodiment, a mismatch will arise if the current virtual stack and 
snapshot do not contain the same number or types of entries. The verifier will then set a verification status value 245 
for the program to false, and abort (442) the verification process. Setting the verification status value 245 for the program 
to false prevents execution of the program by the bytecode interpreter 242 (Figure 2). 

If the current virtual stack and the stored stack snapshot for the current instruction match (438), then the verifier will 
continue the verification process and analyze the individual instruction, starting at step 450, as described below. 

If the address of the currently selected instruction is not found within the directory portion 348 of the stack snapshot 
storage structure 346 or if a stack status mismatch is not detected, then the verifier performs selected ones of a series 
of checks on the instruction depending on the particular instructions stack usage and function. 

Referring to Figure 4C, the first check to be performed concerns instructions that pop data from the operand stack. 
If the currently selected instruction pops data from the stack (450), the stack counter is inspected (452) to determine 
whether there is.sufficient data in the stack to satisfy the data pop requirements of the instruction. 

If the operand stack has insufficient data (452) for the current instruction, that is called a stack underflow, in which 
case an error signal or message is generated (454) identifying the place in the program that the stack underflow was 
detected. In addition, the verifier will then set a verification status value 245 for the program to false, and abort (456) the 
verification process. 

If no stack underflow condition is detected, the verifier will compare (458) the data type code information previously 
stored in the virtual stack with the data type requirements (if any) of the currently selected instruction. For example, if 
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the opcode of the instruction being analyzed calls for an integer add of a value popped from the stack, the verifier will 
compare the operand information of the item in the virtual stack which is being popped to make sure that is of the proper 
data type, namely integer. If the comparison results in a match, then the verifier deletes (460) the information from the 
virtual stack associated with the entry being popped and updates the stack counter 342 to reflect the number of entries 

5 popped from the virtual stack 344. 

If a mismatch is detected (458) between the stored operand information in the popped entry of the virtual stack 344 
and the data type requirements of the currently selected instruction, then a message is generated (462) identifying the 
place in the bytecode program where the mismatch occurred. The verifier will then set a verification status value 245 
for the program to false and abort (456) the verification process. This completes the pop verification process. 

io Referring to Figure 4D, if the currently selected instruction pushes data onto the stack (470), the stack counter is 
inspected (472) to determine whether there is sufficient room in the stack to store the data the selected instruction will 
push onto the stack. If the operand stack has insufficient room to store the data to be pushed onto the stack by the 
current instruction (472), that is called a stack overflow, in which case an error signal or message is generated (474) 
identifying the place in the program that the stack underflow was detected. In addition, the verifier will then set a verif i- 

75 cation status value 245 for the program to false, and abort (476) the verification process. 

If no stack overflow condition is detected, the verifier will add (478) an entry to the virtual stack indicating the type 
of data (operand) which is to be pushed onto the operand stack (during the actual execution of the program) for each 
datum to be pushed onto the stack by the currently selected instruction. This information is derived from the data type 
specific opcodes utilized in the bytecode program of the preferred embodiment of the present invention. The verifier also 

20 updates the stack counter 342 to reflect the added entry or entries in the virtual stack. This completes the stack push 
verification process. 

Referring to Figure 4E, if the currently selected instruction causes a conditional or unconditional jump or branch 
forward in the program beyond the ordinary sequential step operation (step 480) the verifier will first check (482) to see 
if a snapshot for the target location of the jump instruction is stored in the stack snapshot storage structure 346. If a 

25 stack snapshot has not been stored, then the virtual stack configuration (subsequent to any virtual stack updates asso- 
ciated with the jump) is stored (484) in the stack snapshot storage structure 346 at a location associated with the target 
program location. Note that any stack pop operations associated with the jump will have already been reflected in the 
virtual stack by the previously executed step 460 (see Figure 4C). 

If a stack snapshot has been stored (indicating that another entry point associated with this target instruction has 

30 already been processed), then the verifier compares (486) the virtual stack snapshot information stored in the snapshot 
portion 340 of the stack snapshot storage structure 346 with the current state of the virtual stack. If the comparison 
shows that the current state and the snapshot do not match, then an error message is generated (488) identifying the 
place in the bytecode program where the.stack status mismatch occurred. In the preferred embodiment, a mismatch 
will arise if the current virtual stack and snapshot do not contain the same number or types of entries. Furthermore, a 

35 mismatch will arise if one or more data type values in the current virtual stack do not match corresponding data type 
values in the snapshot. The verifier will then set a verification status value 245 for the program to false and abort (490) 
the verification process. If a stack status match is detected at step 486, then the verifier continues processing at step 
500 (Figure 4F). 

Referring to Figure 4F, if the currently selected instruction causes a conditional or unconditional jump or branch 

40 backward in the program (step 500) then the verifier compares (502) the virtual stack snapshot information stored in the 
snapshot portion 340 of the stack snapshot storage structure 346 associated with the target of the backward jump (which 
has already been stored in step 436) with the current state of the virtual stack. If the comparison shows that the current 
state and the snapshot do not match, then an error message is generated (504) identifying the place in the bytecode 
program where the stack status mismatch occurred. In the preferred embodiment, a mismatch will arise if the current 

45 virtual stack and snapshot do not contain the same number or types of entries or if any data type entry in the current 
virtual stack does not match the corresponding data type entry in the snapshot. The verifier will then set a verification 
status value 245 for the program to false and abort (506) the verification process. 

If a stack status match is detected (at step 502) or if the instruction is not a backward jump (at step 500), then the 
verifier continues processing at step 510. 

so . If the currently selected instruction reads data from a local variable (510), the verifier will compare (512) the data 
type code information previously stored in the corresponding virtual local variable with the data type requirements (if 
any) of the currently selected instruction. If a mismatch is detected (512) between the data type information stored in 
the virtual local variable and the data type requirements of the currently selected instruction, then a message is generated 
(514) identifying the place in the bytecode program where the mismatch occurred. The verifier will then set a verification 

55 status value 245 for the program to false and abort (516) the verification process. 

If the currently selected instruction does not read data from a local variable (510) or the data type comparison at 
step 512 results in a match, then the verifier continues processing the currently selected instruction at step 520. 

Referring to Figure 4G. if the currently selected instruction stores data into a local variable (520), the corresponding 
virtual local variable is inspected (522) to determine whether it stores a data type value. If the virtual local variable does 
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store a data type value (indicating that data has been previously stored in the local variable), the verifier compares the 
data type information in the virtual local variable with the data type associated with the currently selected bytecode 
instruction (524). If a mismatch is detected (524) between the data type information stored in the virtual local variable 
and the data type requirements of the currently selected instruction, then a message is generated (526) identifying the 
place in the bytecode program where the mismatch occurred. The verifier will then set a verification status value 245 
for the program to false and abort (528) the verification process. 

If the currently selected instruction does not store data into a local variable (520) processing for the currently selected 
instruction is completed. If the currently selected instruction stores data into a local variable, but the virtual local variable 
does not store a data type value (indicating that no instruction which would store data in the local variable has yet been 
processed by the verifier), then the data type associated with the selected bytecode instruction is stored in the virtual 
local variable (step 530). 

Next, the verifier checks (540) to see if this is the last instruction in the bytecode program 340 to be processed If 
more instructions remain to be processed, then the verifier loads (542) the next instruction, and repeats the verification 
process starting at step 432. If no more instructions are to be processed, then the verifier will then set a verification 
status value 245 for the program to True (544), signaling the completion of the verification process. 

Bytecode Interpreter 



Referring to flow chart in Figure 5 and Appendix 2, the execution of the bytecode interpreter 242 will be described 
Appendix 2 lists a pseudocode representation of the bytecode interpreter. 

After a specified bytecode program has been received or otherwise selected (560) as a program to be executed 
the bytecode program interpreter 242 calls (562) the bytecode verifier 240 to verify the integrity of the specified bytecode 
program. The bytecode verifier is described above. 

If the verifier returns a "verification failure" value (564). the attempt to execute the specified bytecode program is 
aborted by the interpreter (566). 

If the verifier 242 returns a "Verification Success" value (564). the specified bytecode program is linked (568) to 
resource utility programs and any other programs, functions and objects that may be referenced by the program Such 
a linking step is a conventional pre-execution step in many program interpreters. Then the linked bytecode program is 
interpreted and executed (570) by the interpreter. The bytecode interpreter of the present invention does not perform 
any operand stack overflow and underflow checking during program execution and also does not perform any data type 
checking for data stored in the operand stack during program execution. These conventional stack overflow underflow 
and data type checking operations can be skipped by the present invention because the interpret has already verified 
that errors of these types will not be encountered during program execution. 

The program interpreter of the present invention is especially efficient for execution of bytecode programs having 
instruction loops that are executed many times, because the operand stack checking instructions are executed only once 
for each bytecode in each such instruction loop in the present invention. In contrast, during execution of a program by 
a convention interpreter, the interpreter must continually monitor the operand stack for overflows (i.e. adding more data 
to the stack than the stack can store) and underflows (i.e.. attempting to pop data off the stack when the stack is empty) 
Such stack monitoring must normally be performed for all instructions that change the stack's status (which includes 
most all instructions). For many programs, stack monitoring instructions executed by the interpreter account for approx- 
imately 80% of the execution time of an interpreted computed program. As a result, the interpreter of the present invention 
will often execute programs at two to five times the speed of a conventional program interpreter running on the same 
computer. 

The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of 
illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed 
and obviously many modifications and variations are possible in light of the above teaching. The embodiments were 
chosen and described in order to best explain the principles of the invention and its practical application to thereby 
enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are 
suited to the part.cular use contemplated. It is intended that the scope of the invention be defined by the Claims appended 
hereto and their equivalents. 
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TABLE 1 

BYTECODES IN OAK LANGUAGE 



10 



15 



25 



30 



35 



40 



45 



50 



INSTRUCTION NAME 

aaload 

aastore 

aconst_null 

aload 

areturn 

arraylength 

astore 

astore_<n> 

athrow 

bipush 

breakpoint 

catchsetup 

catchteardown 

checkcast 

df2 

d2i 
d2l 

dadd 
daload 
dastore 
dcmpg 

dcrnpl 

dconst_<d> 

ddiv 

dload 

dload_<n> 

dmod 



SHORT DESCBlEIlQtJ 



load object reference from array 

store object reference into object reference array 

push null object 

load local object variable 

return object reference from function 

get lenth of array 

store object reference into local variable 

store object reference into local variable 

throw exception 

push one-byte signed integer 

call breakpoint handler 

set up exception handler 

reset exception handier 

make sure object is of a given type 

convert double floating point number to single 

precision floating point number 

convert double floating point number to integer 

convert double floating point number to long 

integer 

add double floating point numbers 
load double floating point number from array 
store double floating point number into array 
compare two double floating point numbers (return 
1 on incomparable) 

compare two double floating point numbers (return 

-1 on incomparable) 

push double floating point number 

divide double floating point numbers 

load double floating point number from local 

variable 

load double floating point number from local 
variable 

perform modulo function on double floating point 
numbers 
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dmul miltiply double floating point numbers 

dneg negate double floating point number 

dretum return double floating point number from function 

dstore store double floating point number into local 

variable 

dstore_<n> store double floating point number into local 

variable 

dsub subtract double floating point numbers 

dup duplicate top stack word 

dup2 duplicate top two stack words 

dup2_x1 duplicate top two stack words and put two down 

dup2_x2 duplicate top two stack words and put three down 

dup_x1 dulicate top stack word and put two down 

dup_x2 duplicate top stack word and put three down 

f2d convert single precision floating point number to 

- - doujbre*floating poM nwmb^r * " 

f 2 ' convert single precision floating point number to 

integer 

convert Single precision floating point number to 
long integer 

* add add single precision floating point numbers 

faload load single precision floating point number from 

array 

fastore store into single precision floating point number 

array 

fem P9 compare single precision floating point numbers 

(return 1 on incomparable) 
fem P* compare Single precision floating point number 

(return -1 on incomparable) 
fconst_<f> push single precision floating point number 

fdiv divide single precision floating point numbers 

f,oad load single precision floating point number from 

local variable 

fload_<n> load single precision floating point number from 

local variable 

frnod perform modulo function on single precision 

floating point numbers 
fmul multiply single precision floating point numbers 
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10 



75 



20 



25 



30 



35 



40 



45 



50 



fneg 
fret urn 

fstore 

fstore_<n> 

fsub 

getfield 

getstatic 

goto 

i2d 

i2f 

121 

iadd 

iaload 

iand 

iastore 

iconst_<n> 

iconst_m1 

idiv 

if_acmpeq 

if_acmpne 

if_icmpeq 

iMcmpge 

iMcmpgt 

iMcmple 

if_icmplt 

if_icmpne 

ifeq 

ifge 

ifgt 

ifle 
if It 
ifne 
iinc 
iload 



negate single precision floating point number 
return single precision floating point number from 
function 

store single precision floating point number into 
local variable 

store single precision floating point number into 
local variable 

subtract single precision floating point numbers 
fetch field from object 
set static field from class 
branch always 

convert integer to double floating point number 
convert integer to single precision floating point 
number 

convert integer to long integer 
add integers 
load integer from array 
boolean AND two integers 
store into integer array 
push integer 

push integer constant minus 1 

integer divide 

branch if objects same 

branch if objects not same 

branch if integers equal 

branch if integer greater than or equal to 

branch if integer greater than 

branch if integer less than or equal to 

branch if integer less than 

branch if integers not equal 

branch if equal to 0 

branch if greater than or equal to 0 

branch if greater than 0 

branch if less than or equal to 0 

branch if less than 0 

branch if not equal to 0 

increment local variable by constant 

load integer from local variable 
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iload_<n> load integer from local variable 

imod peform modulo function on integers 

imul multiply integers 

in ©9 negate integer 

instanceof determine if object is of given type 

ir »t2byte convert integer to signed byte 

int2char convert integer to char 

invokeinterface invoke interface method 

invokemethod invoke class method 

invokesuper invoke superclass method 

ior boolean OR two integers 

iretum return integer from function 

lshl integer shift left 

,shr integer arithmetic shift right 

,store store integer into local variable vindex 

l^o^<n^ r .... . : Sip.^L^ 

isub subtract integers 

iushr integer logical shift right 

ixor boolean XOR two integers 

i sr jump to subroutine 

12d convert long integer into double floating point 

number 

12f convert long integer into single precision floating 

point number 

12i convert long integer into integer 

' add add long integers 

la,oad load long integer from array 

,and boolean AND two long integers 

lastore store into long integer array 

lcm P compare long integers 

lconst_<l> p U sh long integer constant 

ldc1 push item from constant pool 

ldc2 push item from constant pool 

ldc2w Push long or double from constant pool 

,div divide long integers 

,Ioad load long integer from local variable 

lload_<n> | oac | | ong integer from local variable 

,mod perform modulo function on long integers 
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Imul 


multiply long integers 


5 


Ineg 


Negate long integer 




lookupswitch 


Access jump table by key match and jump 




lor 


boolean OR two long integers 


70 


Iretum 


return long integer from function 




Ishl 


long integer shift left 




Ishr 


long integer arithmetic shift right 




Istore 


store long integer into local variable 


75 


lstore_<n> 


store long integer into local variable 




Isub 


subract long integers 




lushr 


long integer logical shift right 


20 


Ixor 


boolean XOR long integers 




monitorenter 


enter monitored region of code 




monitorexit 


exit monitored region of code 


25 


new 


create new object 




newarray 


allocate new array 




newfromname 


create new object from name 




nop 


do nothing 


30 


pop 


pop top stack word 




pop2 


pop top two stack words 




putfield 


set field in object 


35 


putstatic 


set static field in class 




ret 


return from subroutine 




return 


return (void) from procedure 


40 


saload 


load signed byte from array 




sastore 


store into signed byte array 




siaload 


load unsigned short from array 




siastore 


store into unsigned short array 


45 


sipush 


push two-byte signed integer 




tableswitch 


access jump table by index and jump 




verifystack 


verify stack empty 



so 
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APPENDIX 1 
Pseudocode for OAK Bytecode Verifier 



Receive Bytecode Program to be verified. 

Create Virtual Operand Stack Data Structure for storing stack status 
information and Virtual Local Variable Array for storing local variable data 
type information. 

Create data structure for storing Virtual Stack Snapshots. 

First Pass through Bytecode Program: 

Locate all instructions that are the targets of conditional and 
unconditional jumps or branches (i.e., can be entered from more than one 
prior instruction). 

Store list of such target instructions in Virtual Stack Snapshot data 
structure. 

Second Pass through Bytecode Program: 
Set VerificationSuccess to True 

Do Until Last Bytecode Instruction has been processed" 
{ 

Select next bytecode instruction (in sequential order in program) 
If instruction is in list of target instructions 



If snapshot of virtual stack for this instruction already exists 
{ 

Compare current state of virtual stack with stored snapshot 
If snapshot does not match current virtual stack state 
{ 

Print message identifying place in program that stack 

mismatch occurred 

Abort Verification 

Set VerificationSuccess to False 

Return 



Else 



Store snapshot of current virtual stack status 
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} 



Case(lnstruction Type): 
{ 

Case=lnstaiction pops data from Operand Stack 
{ 

Check for Stack Underflow 
If Stack has Underflowed 
{ 

Print message identifying place in program that 
underflow occurred 
Abort Verification 
Return 

} 

Compare data type of each operand popped from stack with 
data type required (if any) by the bytecode instruction 
If type mismatch 



Print message identifying place in program that data type 

mismatch occurred 

Set VerificationSuccess to False 



Delete information from Virtual Stack for popped operands 

Update Stack Counter 

} 

Case=lnstruction pushes data onto Operand Stack 
{ 

Check for Stack Overflow 
If Stack has Overflowed 
{ 

Print message identifying place in program that overflow 

occurred 
Abort Verification 
Set VerificationSuccess to False 
Return 

} 
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Add information to Virtual Stack indicating data type of data 
pushed onto operand stack 
Update Stack Counter 
} 

Case=lnstruction is a forward jump or branch instruction 
{ 

If snapshot of virtual stack for the target instruction already 
exists 

{ 

Compare current state of virtual stack with stored 
snapshot 

If snapshot does not match current virtual stack state 
{ 

Print message identifying place in program that stack 

mismatch occurred 

Abort Verification 

Set Verifications uccess to False 

Return 

} 

} 

Else 

Store snapshot of current virtual stack state as snapshot 
for the target instruction; 

} 

Case=lnstruction is an end of loop backward jump or other 
backward jump or branch instruction 
{ 

Compare current virtual stack state with stored snapshot for 
target instruction 

If current virtual stack state does not match stored snapshot 

Print message identifying place in program that stack 
mismatch occurred 
Abort Verification 

Set VerificationSuccess to False 
Return 
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Case=lnstruction reads data from local variable 
{ 

Compare data type of each datum read from local variable 
with data type required (if any) by the bytecode instruction 
If type mismatch 



Print message identifying place in program that data type 

mismatch occurred 

Set VerificationSuccess to False 

} 



Case=lnstruction stores data into a local variable 
{ 

If corresponding virtual local variable already stores a data 
type value 

{ 

Compare data type value stored in virtual local variable 
with data type of datum that would be stored in the 
corresponding local variable (as determined by the data 
type handled by the current bytecode instruction) 
If type mismatch 



{ 

Print message identifying place in program that data 

type mismatch occurred 

Set VerificationSuccess to False 



Else 

Add information to Virtual Local Variable indicating data 
type of data that would be stored in corresponding local 
variable 



} 
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} r EndCase 7 
5 } r End of Do Loop 7 

Return (VerificationSuccess) 

10 



is APPENDIX 2 

Pseudocode for Bytecode Interpreter 



20 



25 



Receive Specified Bytecode Program to be executed 
Call Bytecode Verifier to verify Specified Bytecode Program 
If Verification Success 
{ 

Link Specified Bytecode Program to resource utility programs. 



Interpret and execute Specified Bytecode Program instructions without 
so performing operand stack overflow and underflow checks and without 

performing data type checks on operands stored in operand stack 
} 



35 



40 



45 



50 



Claims 

1 . A method of operating a computer system, the steps of the method comprising: 

(A) storing a program in a memory, the program including a sequence of bytecodes. where each of a multiplicity 
of said bytecodes each represents an operation on data of a specific data type; said each bytecode having 
associated data type restrictions on the data type of data to be manipulated by said each bytecode 

(B) prior to execution of said program, preprocessing said program by determining whether execution of any 
bytecode in said program would violate said data type restrictions for that bytecode and generating a program 
fault signal when execution of any bytecode in said program would violate the data type restrictions for that 
bytecode; 

(C) when said preprocessing of said program results in the generation of no program fault signals enablinq 
execution of said program; and 

(D) when said preprocessing of said program results in the generation of a program fault, preventing execution 
of said program. 



2. The method of claim 1 , said preprocessing step including: 

55 



(B1) determining the state of a virtual stack associated with said program before and after execution of each 
said bytecode in the program, said virtual stack state storing data type values for operands that would be stored 
in an operand stack during execution of said program; and 
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(B2) determining whether execution of any bytecode in said program would violate said data type restrictions 
for that bytecode and generating a program fault signal when execution of any bytecode in said program would 
violate the data type restrictions for that bytecode. 

5 3. The method of claim 2, 

said bytecode program including at least one execution loop; 
said preprocessing step including 

(B3) determining whether execution of any loop in said program would result in a net addition or deletion 
w of operands to said operand stack, and for generating a program fault signal when execution of any loop in said 

program would produce a net addition or deletion of operands to said operand stack. 

4. The method of claim 3, including 

when execution of said bytecode program has been enabled, executing said bytecode program without per- 
15 forming operand stack underflow and overflow checks during execution of said bytecode program. 

5. The method of claim 1 ,2, 3 or 4, including: 

when execution of said bytecode program has been enabled, executing said bytecode program without per- 
forming data type checks on operands stored in said operand stack during execution of said bytecode program. 

20 

6. The method of claim 1 , 

said bytecode program including at least one execution loop; 
said step (B) including 

determining the state of a virtual stack associated with said program before and after execution of each said 
25 bytecode in the program, said virtual stack state storing data type values for operands that would be stored in an 
operand stack during execution of said program; and 

determining whether execution of any loop in said program would result in a net addition or deletion of oper- 
ands to said operand stack, and for generating a program fault signal when execution of any loop in said program 
would produce a net addition or deletion of operands to said operand stack. 

30 

7. The method of claim 6, including 

when execution of said bytecode program has been enabled, executing said bytecode program without per- 
forming operand stack underflow and overflow checks during execution of said bytecode program. 

35 8. The method of claim 1 , 

said step (B) including determining, whenever two or more bytecodes in said program comprise 
jumps/branches to an identical location in said program, whether the states of the virtual stack prior to execution of 
each of said jump/branches are inconsistent, and tor generating a program fault signal if said virtual stack states 
are inconsistent. 

40 

9. The method of claim 8, 

when execution of said bytecode program has been enabled, executing said bytecode program without per- 
forming operand stack status checks during execution of said bytecode program. 

45 10. A computer system, comprising: 

memory for storing a bytecode program, the bytecode program including a sequence of bytecodes, where 
each of a multiplicity of said bytecodes each represents an operation on data of a specific data type; said each 
bytecode having associated data type restrictions on the data type of data to be manipulated by said each bytecode; 
a data processing unit for executing programs stored in said memory; 
so a bytecode program verifier, stored in said memory, said bytecode program verifier including data type testing 

instructions for determining whether execution of any bytecode in said program would violate said data type restric- 
tions for that bytecode and generating a program fault signal when execution of any bytecode in said program would 
violate the data type restrictions for that bytecode; and 

a bytecode program interpreter, coupled to said bytecode program verifier, that executes said bytecode pro- 
55 gram after processing of said bytecode program by said bytecode program verifier only when said bytecode program 
verifier generates no program fault signals. 

1 1 . The computer system of claim 10, 

said bytecode program verifier including 
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stack status tracking instructions for determining the state of a virtual stack associated with said program 
before and after execution of each said bytecode in the program, said virtual stack state storing data type values 
for operands that would be stored in an operand stack during execution of said program; and 

data type checking instructions for determining whether execution of any bytecode in said program would 
violate said data type restrictions for that bytecode and generating a program fault signal when execution of any 
bytecode in said program would violate the data type restrictions for that bytecode. 

12. The computer system of claim 10, said bytecode program verifier further including: 

stack overflow/underflow testing instructions for determining whether execution of said program would result 
in an operand stack underflow or overflow and generating a program fault signal when execution of said program 
would result in an operand stack underflow or overflow. 

13. The computer system of claim 12, said bytecode program interpreter including instructions for executing said byte- 
code program without performing operand stack underflow and overflow checks during execution of said bytecode 



1 4. The computer system of claim 1 0, 1 1 , 1 2, or 1 3 said bytecode program interpreter including instructions for executing 
said bytecode program without performing data type checks on operands used by said bytecode program. 

15. The computer system of claim 10, 

said bytecode program verifier including 

stack status tracking instructions for determining the state of a virtual stack associated with said program 
before and after execution of each said bytecode in the program, said virtual stack state storing data type values 
for operands that would be stored in an operand stack during execution of said program; and 

stack overflow/underflow testing instructions for determining whether execution of said program would result 
in an operand stack underflow or overflow and for generating a program fault signal when execution of said program 
would result in an operand stack underflow or overflow. 

16. The computer system of claim 10, 

said bytecode program interpreter including means for executing said bytecode program without performing 
operand stack underflow and overflow checks during execution of said bytecode program. 

17. The computer system of claim 10. 

said bytecode program verifier including jump/branch inspection instructions for determining, whenever two 
or more bytecodes in said program comprise jumps/branches to an identical location in said program whether the 
states of the virtual stack prior to execution of each of said jump/branches are inconsistent, and for generating a 
program fault signal if said virtual stack states are inconsistent. 

18. The computer system of claim 17, 



said bytecode program interpreter including means for executing said bytecode program without performing 
operand stack status checks during execution of said bytecode program. 



program. 
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Receive and load Bytecode Program into Verifier 
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Generate Error Message identifying place in 
program that data type mismatch occurred 



Stack Pop 
Instruction 
Processing 
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Generate Error Message identifying place in 
program that stack underflow occurred 



Set Verification Status of Program to False. 
Abort Verification. 



456 



460 



Delete information from Virtual Stack for popped operands 
Update Stack Counter 



A 
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Stack Push 
Instruction 
Processing 



Generate Error Message identifying place in 
program that stack overflow occurred 
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Set Verification Status of Program to False. 
Abort Verification. 
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Add information to Virtual Stack for pushed operands. 
Update Stack Counter 
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